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1. Introduction 



This document describes the Sun-3 architecture. It Is intended aa a reference for Sud-3 software, 
hardware, and systems implementors. 

Features. The Sun-3 architecture is an extension of the Sun-2 architecture. Its main features are 
support of the 68020 CPU, the 68881 FPP, 8 KB pages, eight 256 MB contexts, and a 32-bit VMEbui. 
The Sun-3 architecture does not necessarily apply to any future CPUs. 

Nomenclature The nomenclature used in the Sun-3 architure includes terminology common to the 68020 
processor terminology. Eixamples include word defmition, byte addressing, address space dcfition, etc. 
Deviations from thb Domenclature arc noted. Minus active signal names are suffixed with a minus (-). 

Scope. This Sun-3 architecture manual describes all devices which may be included in a Sud-3 CPU 
board plus all boards which are interconnected with the CPU board over a Sun defined memory bus. The 
manual docs not describe devices accessible over the system bus (VMEbus). , 

Implementation. The main part of. this document is independent of particular implementations of the 
architecture. Implementation specific data, such as timing information, need to be specified for each 
implementation. 

Correctness. An important goal of thb document b correctness. Please report any errors, ombsions, or 
oversights immediately so they can be corrected in future revbions. 

1.1. Definitions 

In the subsequent description of the Sun-3 architecture the following abbreviations are used: 

CPU: Central Processing Unit 

DVMA: Direct Virtual Memorj* Access 

MMU: Memory Management Unit 

PMEG: Page Map Entry Group 

POR: Power-On-Reset 

EGG: Error Correcting Code 



Sun Microsyslcms Inc CONFIDENTIAL 16 May 1985 



Sun-3 Architecture Rev 2.0 Prelim 



Introduction 



1.2. Architecture Overview 

The Sun-3 architecture is divided into three spaces: the CPU apace, Control space, and Device space. 

The CPU space comprises all references of the 68020 CPU in function code 7. /"C / *->'♦' •^-/--c 

The Control space is the core of the Sun-3 architecture. It includes the Sun-3 memory management unit 
(the.'MMU') as well as all other Sun-3 architecture extensions to the CPU, such as the bus error regbter, 
the system enable register, the diagnostic register, and the ID-PROM. The ED-PROM contains a unique 
serial number and indicates the implementation type of the architecture. 

The Device space of the Sun-3 architecture defines what devices exist in the architecture and how they 
are accessed. These devices include main memory, the system bus (VMEbus), and I/O devices. 

The CPU may directly access one device, the Floating Point Accelerator, in Device Space without MMU 
address translation and protection checking. 

All other CPU accesses to Device Space pass through the MNfU and thus are translated and protected in 
an identical fashion. In addition, direct memory accesses by DVMA masters such as the Ethernet, SCSI, 
and the VMEbus slave interface also pass through the memory management and thus operate in a fully 
protected environment. • 

The' figure below illustrates how the CPU, MMU, and devices arc interconnected in the Sun-3 
architecture. The CPU sends out a virtual address that is translated by the MMU into a physical address. 
The VMEbus Master Interface, Main Memory, Video Memory, and I/O Devices are addressed with 
physical addresses on the right side of the MMU. 

DVMA devices and the CPU must arbitrate for and share the virtual address bus on the left side of the 
MMU. AmoDng the possible DVMA devices are the Ethernet interface, SCSI interface, VMEbus Slave 
interface, and a Cache Flush Controller, depending on the implementation. Of these devices, the Ethernet 
has the highest priority, a Cache Flush Controller second highest, the SCSI third highest, the VMEbus 
slave interface fourth highest, and the CPU lowest priority. 
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1.3. Implementation Conrigurations 

The Sun-3 architecture allows each implementation of the Sun-3 architecture to have its own 
configuration of devices. In addition, configurations may provide certain options in terms of main 
memory size and I/O devices. With this configuration flexibility come a number of optional bits in 
registers. These Sun-3 implementation configurations are treated uniformly as follows: 

• Machine Configuration, The machine type in the DDPROM indicates which devices the 
machine has and which arc valid options. Addresses for all devices defined in Sun-3 are fixed 
by the Sun-3 architecture. 

• Optional Control Space devices. Control Space devices are decoded from fields of address bits. 
— Most devices are uniquely identified by decoding A<31..28>, but some devices may require 

the use of additional subficlds for unique device identification. Address bits outside defined 
fields are ignored on Control Space accesses. Accesses to unimplemented devices or undefined 
codes are dbcussed in the Bus Error Register section. 

• Optional Main Memory. The minimum and maximum main memory for each Sun-3 machine 
type arc implementation dependent. The smallest minimum main memory size for any S,un-3 
configuration is 2 megabytes. The size of the main memory physical address space, is also 
implementation dependent. Any access to a main memory physical, address beyond the range 
of the maximum physical address space is undefined. Accesses to memory that is addressable, 
but not physically present, are discussed in the Bus Error Register section. 

• Optional I/O Devices. I/O devices are defined as Type 1 devices in Device Space. Most I/O 
devices are uniquely identified by decoding physical address bits A<20..17>, but some devices 
may require the use of additional subfields for unique device identification. Address bits 
outside defined fields are ignored on accesses to Type 1 devices in Device Space. Accesses to 
I/O devices which are optional to an implementation but not installed or to codes undefined in 
an implementation are discussed in the Bus Error Register section. 

• High Order Virtual Addrea Bits. The Sun-3 architecture has 28 bit virtual addressing in 
Device Space. The treatment of virtual address bits A<31..28> for CPU bus cycles in Device 
Space depends on whether the implementation supports the Floating Point Accelerator (FPA) 
option. For those implementations that support the FPA, the only valid codes for A<31..28> 
are 0x0, OxE, and OxF. Code OxE accesses the FPA, and codes 0x0 plus OxF access other 
Device Space devices. Treatment of other codes are discussed in the Bus Error section. For 
those implementations that do not support the FPA, CPU virtual address bits A<31..28> are 
ignored in Device Space. 

• Optional Bits in Registers. The architecture defines certain register bits, such as bits of the 
System Enable register, which control devices that may be optional or may not exist for a 
given implementation. These register bits must exist for all implementations but will have no 
affect in implementations for which the device is non-existent. 

• Unused bits in Page Map. Unimplemented bits in the Page Map Physical Address and 
Reserved fields read back as O's. Unused Page Map control bits may be read and written but 
have no affect. 

• Unused bits in the Cache Tags. For those implementations that support a cache, the Unused 
cache tag bits D<7..0> and unused Virtual Address tags are undefined. The Reserved lag 
bits D<20..28> and D<11> may be read and written but have no affect. 
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2. Address Spaces 

The Sun-3 architecture uses three address spaces: CPU Space, Control Space, and Device Space. These 
address spaces are decoded with different processor function codes. 

The following table describes how different CPU function codes are mapped to the CPU, Control, and 
Device space. 



FC 


Addrtat Sp&ca 





Rattrrtd 


1 


D«Tic« spue* CUi«r Data) 


2 


DtTlct Spac* (Uf*r Profraa) 


S 


Control Spact 


4- 


R«s«nrtd 


6 


D«Tic« Spac* (Snparriior Data) 


e 


D«t1c« Spacf (Sopwrvisor Profraa) 


7 


CPU Spac* 



2.1. CPU Space 

CPU space consbts of all cycles that use function code 7. These include coprocessor cycles, interrupt , 
acknowledge, breakpoint and ring-protection cycles. 

2.2. Control Space 

Control space consists of all cycles that use function code 3. These include accesses to the memory 
management unit (the •MNiU*), the bus error reg'ister, the system enable regbter, the user enable register, 
the diagnostic register, the ED-PROM, several cache related functions (if implemented), and an (optional) 
bypass path to the UART. 

2.3. Device Space 

Device space includes all devices that are accessed by the CPU with data or program space instructions. 
These devices include main memory, the VNIEbus Master interface, I/O devices, and so on. All devices in 
Device Space, with one exception, are accessed via the MMU. This allows these devices to be protected, 
shared, and managed in a uniform manner in a multiprocess environment. The one exception is an 
optional Floating Point Accelerator, which is accessed by direct decoding of CPU virtual address bits 
A<31..28>. The chapter on the FPA describes how this device b protected and shared. 
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3. CPU Space 



CPU space consbts of all cycles that use function code 7. This includes coprocessor cycles, interrupt, 
breakpoint and ring-protection cycles. 

3.1. CPU Space Cycles 

In the Sun-3 architecture, address bits A<17..16> are decoded to determine the type of CPU Space 
cycle as follows: 



CYCLE TYPE A17 A16 CYCLE COJTCIJUSIOI 

BREAKPOIIIT CYCLE 

BIJIGPROTECTIOM 

CtJPROCESSOR CYCLE 1 

IITERaUPT ACX. CYCLE 1 

Breakpoint and ringprotection cycles are terminated with Bus Error. 
Interrupt acknowledge cycles are dbcussed in the chapter on CPU Interrupts. 






BERJl 


1 


BERn 





DSACKABERR 


1 


AVBC/DSACK/BERR 



3.2. Coprocessor Cycles 

The execution of ■F-line" opcodes results in coprocessor bus cycles. There are "eight possible 
coprocessors, identified by address bits A15 through A13. Sun-3 systems support one coprocessor, the 
MCC888I Floating Point coprocessor (FPP). This coprocessor is identified by A<15..13> = '001' and a 
is enabled by bit D<6> of the System Enable register. 

"F-line" opcode instructions will terminate with an unimplemented instruction exception if external 
hardware asserts the bus error signal to terminate the coprocessor cycle. Three conditions cause thb 
exception: first, access to any coprocessor except the FPP (i.e., any coprocessor code except A<15..13> 
= '001'); second, access to the FPP while disabled (i.e., with EN.FPP = 0); and third, access to an 
enabled (EN.FPP =» 1) but non-responding FPP. None of these conditions cause changes to the Bus Error 
register. 
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4. Control Space 



Control Space includes the Sun-3 memory management unit and all Sun-3 architectural extensions to the 
CPU. These extensions include the bus error register, the system enable register, the user enable register, 
the diagnostic register, the ID-PROM, cache functions (if implemented), and an (optional) bypass path to 
the UART. 



4.1. Access to Control Space Devices 

Space devices). Control Space devices are decoded from fields of address bits. Most devices are uniquely 
identified by decoding A<31..2S>, but some devices may require the use of additional subHelds for 
unique device identification. Address bits outside defined fields are ignored oq Control Space accesses. 
Accesses to unimplemented devices or undefined codes are discussed in the Bus Error Regkter section. 

Control Space devices are identified by decoding fields of address bits. Most devices are uniquely 
identified by decoding A<31..28>, but some devices may require the use of additional subfields for 
unique device identification. The Flush Cache Control Space operation requires decoding data bits 
D<1..0> to uniquely identify the type of flush operation. 

Each Control Space device has an associated address space for accessing elements within the device. (For 
some devices this may be a null space.) These address spaces are shown in the summary table below. In 
this table, CX indicates the Context ID register. 



RECISTER/MAP A<S1 


..28> 


D<1..0> 


SIZE 


TYPE 


ADDRESS Fin.D 




ID PROM 


0x0 




BYTE 


READ 


A<4..0> 




PAGE MAP 


0x1 




LONG 


R/f 


CX<2..0>. A<27. 


.i3> 


SECMEXT MAP 


0x2 




BYTE 


R/9 


CX<2..0>. A<27. 


.17> 


COHTDCT REC. 


OxS 




BYTE 


R/f 






SYSTEM EXAHIJ: 


0x4 




BYTE 


R/1 






USER DVIA EH ART .E 


0x5 




BYTE 


RA 






BUS ERROR REC. 


0x0 




BYTE 


READ 






DIACHOSTIC REC. 


0x7 




BYTE 


TRITE 






CACHE TAGS 


0x8 




LOSG 


R/1 


A<16..4>« 




CACHE DATA 


0x9 




LOBC 


R/1 


A<16..2>« 




FLUSH CACHE 


OxA 


•01* 


I/A 


IRITE 


CX<2..0>, A<ie. 


.4>«» 


SET (COMTDCT) 














FLUSH CACHE 


OxA 


•10* 


«/A 


WRITE 


CX<2..0>, A<27. 


.15>. 


aU (PAGO 










A<12..4>»» 




FLUSH CACHE 


OxA 


•ir 


H/A 


IRITE 


CX<2..0>, A<27. 


.17>. 


SET (SECttEKT) 




- 






A<18..4>«» 




mXiCt COPY (READ) 


OxB 




M/A 


READ 


CX<2..0>. A<27. 


.A> 


BLOCK COPY (WRITE) 


OxB 




«/A 


IRITE 


CX<2..0>. A<27. 


.4> 


Unniid 


OxC. 


• OxE 










UART BYPASS 


OxT 




BYTE 


R/1 


A<2..1> 





• D«p«ndt on b1i« of c»cht: >*• Control Spic* Op»ratlonf for tht C^ch* 
*• D*p»Dd» on (iz«t of c»cb* ksd Finch S«t: «•• c&cb* Control Sp&c* Opt 



The UART is normally accessed through the MNiU as a Type 1 device in Device Space. Sun-3 
implementations may provide an optional bypass path in Control Space to access the UART directly. 

Accesses to Control Space devices which are optional to an implcmcnlation but not installed or to codes 
undcflDcd in an implementation are discussed in the Bus Error Register section. 
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4.2. Sun-3 Memory Management Unit Summary 



4.2.1. MMU: Summary 



pk^t tis*: 


8 KBjtti 


••(BtiDt vlx*: 


128 KBjttt 


|>roc««s fix*: 


2B6 KBjrttt 


• of cont«zt«: 


8 



• of ••CB»&t«/cont«zt: 204B 
I of pfc(«t/s»(««nt: ~ 10 

t of paact: 2M 

• of f*4*» totnl: 4009 

• of t*(a*&ts total: 10S84 



4.2.2. MMU: Address Translation 



2 27 



17 18 IS 12 



VirtQul Addratt I (S)| | (11) | (4) | (13) 




Stgvtnt Kap: I (8) I 



p»»j • 

I 



21 28 27 24 23 10 18 



Pag* Map: 111111111(2)11111 i^ \ (Ifi/U) I 

T « • X tjp a ■ r»a«rTtd phjtical paja i 

I 
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w: writa accata bit 

•: >jtt«B accaaa bit 

z: don't cacha bit 

a; accaiaad bit 

b: Bodifiad bit 



pbjfical addrata (32/24) C^*^ PH // 



tjpcOO: akin aaaorj 

typ=01: Sun-S I/O apaca 

tjpnlO: VTCEbai 16-blt data 

typ=ll: \TfEbo8 32-blt data 
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4,3. MMU Overview 



The memory management conaista of a context register, a segment map, and a page map. Virtual 
addresses from the processor and DVMA devices arc translated into intermediate addresses by the 
segment map and then into physical addresses by the page map. The MMU uses a page size of 8K bytes 
and a segment size of 128K bytes. Eight contexts with an address space of 256M bytes each are provided. 



4.4. Contexts 

The Sun-3 MMU is divided into 8 distinct address spaces or "contexts*. The current context b selected 
by means of a 3-bit context regbter. The same context applies to both user and supervisor state. 
Initl&lizktion: lon» 



RECISTER/KAP A<S1..28> D<i..O> SIZE 


TYKE 


ADDRESS rinj) 


COHTEXT REG... 0x3 BYTE 


R/1 






COHTEXT RECISTDl 


BIT lAKC KEAXIKC 







D<2..0> CX<2..0> S bit Cc&tazt I.D. 

D<3> RtfarTtd R*««rT«d: Rt»d« back *.» 

D<7..4> Undtflntd Conttntt o&dafintd vb«& r«k4 



4.5. Segment Map 

The segment map has 1C384 entries. It b indexed by the 3 bits of the current context register and the 
11 most significant bits of the virtual address, bits 27 through 17. Thus, the segment map b divided into 
8 contexts of 2048 entries each. Segment map entries are 8 bits wide, pointing to a page map entry group 
(pmeg). 



REGISTER/IAP A<31..28> D<1..0> SIZE TYPE ADDRESS FIELD 
SEGJCJfT lAP 0x2 BYTE R/f CX<2. .0>, A<27..17> 



4.6. Page Map 

The page map contains 4096 page entries each mapping an 8K byte page. Page map entries are 
composed of a valid bit, protection field, don't cache bit, type field, accessed and modified bits, and a page 
number. 

The page map b divided into 255 sections of 16 entries each. Each section is pointed to by a segment 
map entry and b called a page map entry group, or pmeg. 



REClSTEH/ttAP A<31..2B> D<1..0> SIZE TYPE ADDRESS FIELD 



PACE KAP Oil LOKC R/1 CX<2..0>. A<27..1S> 
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4.6.1. Valid Bit 

The valid bit means that the page entry b valid. It also allows read and execute access to the page. 

4.6.2. Write Bit 

The write bit allows write access to the page. 

4.6.3. Supervisor Bit 

If the supervisor bit b set, the read and write access protection apply only to supervisor accesses, and 
user accesses are prohibited. If the supervisor bit b clear, then read and write access protection apply 
both to supervbor accesses and user accesses. 

4.6.4. Don't Cache Bit 

If thb bit b set then the page refereo d will not be cached in a Sun-3 external cache. The Don't Cache 
bit has no affect.on the use of the iC68020 internal instruction cache. It is meaningful only for 
implementations of the Sun-3 archite< ire that include an external cache. In these implementations, the 
bit only has meaning for Type paf.e in Device Space. In machines without a cache the bit can be read 
and written but has no effect. 

4.6.5. PageType 

The 2-bit page type field provides for four physical address spaces, each starting at a physical address of 
0. The four types are: 

PttAP<27..26>: TYPE 

- Biin Vtiorj 

1 - I/O D«Tlc«» 

2 - VHEba« 16-blt di.t«. 
8 - VlEbo» 52-bit d»ta 



4.6.6. Statistics Bits: Accessed and Modified 

The accessed bit b set whenever a page b accessed, on read or write cycles, through the MMU. The 
modified bit is set whenever a page is modified (written into) through an MMU page access. The statbtics 
bits are automatically updated for all cycles requiring an MMU access except if the page b invalid or 
protected. 

PitAP<25>: ACCESSED 

- lot Accii>*d 

1 - Accctod 
PkAP<24>: jrODIFIED 

- lot Kodlfl^d 

1 - lodlMtd 

In SuD-3 implementations with a cache, the accessed and modified bits are only updated on memory 
accesses that "miss* the cache. The sections "The MMU Access Bit" and •Modified Bits for the Cache 
and MMU' in the Cache chapter further discuss statistic bit updates in systems with a cache. 
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4.6.7. Reserved Field 

The reserved field in the page map has no function. It can be written into, but it always reads back as 
0. 

P»AP<2«..10>: RESERVED 



4.6.8. Physical Page Number 

The page number field in conjunction v/itb the byte address generates the physical address. The 
physical page number field is either 11 bits or 19 bits wide. In conjunction with the 13-bit physical byte 
number, the 11-bit physical page number field generates a 24-bit physical address field, whereas the 19-bit 
physical page number field generates a 32-bit physical address field. In case of the 11-bit physical page 
number field, the unused map bits <18..12> have no function; they can be written into, but they always 
reads back as 0. 

The size of the physical address space for each device is limited to be no larger than the size of the 
physical address field in the MMU, but may be less. For Type space (main memory), the size of the 
physical address space is implementation dependent. For Type 1 space (I/O space), the size of the physical 
address space is device dependent. For Type 2 and 3 (VMEbus) space, the physical address space may be 
32, 24, or 16 bits. 

PilAP<19..0>: PAGE KUKBER 
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4.7. ID PROM 

The purpose of the ID PROM is to provide tDformation about the machine. This includes basic 
inrormatioD on the machine type, a unique serial number for software licensing and distribution, a unique 
Ethernet address, the date of manufacturing, and a checksum. In addition, the ID PROM stores 
configuration data for the machine. 

The ID PROM is a 32 byte bipolar PROM that is not modifiable. 



RFfllSTER/KAP A<31..28> D<l.".b> SIZE 


TYPE 


ADDRESS FIELD 


ID PROM 0x0 BYTE 


READ 


A<4..0> 




I/D PBOi 


BYTE lAIE MEAimC 



0x00 


ID PROM 


ID ?rom bytt 


0x0 1 


ID PROM 1 


ID ProB bjt* t 


0x02 


' ID PROM 2 


ID Pro« bjt* 2 


OxlF 


ID PROM 31 


ID Pro* bjtt 31 



The content of the ED PROM is as follows: 



Entry Fl«ld 






(1) For.kt 


1 Bjt» 




C2) Michla* Tjp» 


1 Byt« 




CS) Eth«r&«t Addrtsi 


6 Bjtas 




(4) Dfct* 


4 Bjt«f 




(6) Siri»l lub«r 


3 Bjtaa 




(0) Cb«clc«ua 


I Bjtt 




(7) Rttarrtd 


16 Bjtac 





In detail: 

(1) Format. The format of the ED PROM. 

(2) Machine Type. A number specifying an implementation of the architecture. 

(3) Ethernet Address. This is the unique 48-bit Ethernet address assigned by Sun to thb machine. 

(4) Date. The date the ID PROM was generated. It is in the form of a 32-bit long word which contains 
the number of seconds since January 1, 1970. 

(5) Serial Number. This is a 3-byte serial number. 

(6) Checksum. The checksum is defined such that the longitudinal XOR of the first IG bytes of the 
PROM including the checksum yields 0. 

(7) Reserved. This field will be specified in a future revision of this document. 
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4.8. System Enable Register 

The System Enable Register enables system facilities and allows booting. This register can be read, and 
written under software control and is cleared on Power On (hardware reset) and Watchdog reset, but not 
upon CPU reset. Bits are assigned as follows: 
Inltiklisttlon: S** chipttr on CFM R»i«t 



RECISTEHyitAP A<S1,.28> D<1..0> SIZE TYPE ADDRESS FIELD 
SYSTEM OABIX 0x4 " BYTE R/f 



The fields of the system enable regbter are as follows: 

STSTEM EHABLE EECISTER 



BIT tkHZ KEAIIIIG 



Rtiul bkck dlkgaottlc tvltch 

Enabl* FloLtlDg Point Acctl«ra.tor 

En&bl« copj Mods to Tldto ■•aorj, it prattnt 

En&bl* Tid«c dlsplt.7 

En&bl* (zte <\B.l Ck^ch* it pr»t«nt 

Eni.bl« «JR a DWA if prtfcnt 

En&bl* tl'it'^itig point procvtaor if prtat&t 

Elsa.bl* Scot St&t* (0 k> boot, 1 c> Borsk.!) 



D<0> 


a. 


.DIAC 


D<1> 


EI, 


.FPA 


D<2> 


El, 


.COPY 


D<S> 


EX 


.VIDEO 


D<4> 


ES 


.CACHE 


D<5> 


EX 


.SDVXA 


D<8> 


a 


.FPP 


D<7> 


EH 


.BOOT- 



When cleared on reset, all bits are ini'^ialized to 0. In this state, boot state is active whereas all other 
enabled devices are disabled. 

EN.DIAG. Thb bit reads back the external diagnostic switch. A "O" bit read means that the switch is 
ia its normal state (not-diagnostic), whereas a '!■ means that the switch is activated (diagnostic). 

EN.FPA. Enable the Floating Point Accelerator, if present. If this bit is deasserted, then accesses to the 
FPA cause a bus error, setting the FPAENERR error bit in the Bus Error register. If the bit b asserted, 
accesses are directed to the FPA. In the later case, if no FPA is present, then the access will result in a 
TIMEOUT bus error recorded in the Bus Error register. 

EN.COPY. This bit enables the copy update mode to the video memory, if present. 

EN.VIDEO. This bit enables the video signal to the video monitor, if present, 

EN.CACHE. This bit enables the external cache, if present. 

EN.SDVMA. This bit enables the system DVMA from the system bus (VNlEbus), if present. 

EN.FPP. This bit enables the floating point coprocessor (FPP), if present. See the section 'Coprocessor 
Cycles" in the CPU Space chapter for a description of instruction exceptions resulting from accesses to the 
FPP coprocessor while (EN.FPP = 0). 

EN.B0OT-. Boot state (minus active) forces all supervisor program fetches to the EPROM device 
independent of the setting of the memory management. All other types of references are unaffected and 
will be mapped as during normal operation of the processor. 
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4.9. User DVMA Enable Register 

On implementations of the architecture that allow user DVMA, this register controls which contcxt« 
have DVIvlA access. For each context, a separate enable bit is provided. 
Inltlfclixiktloa: S*« cbt^ptar on CPU R*t«t 



REGISTER/MAP A<31. .28> D<1. .0> SIZE TYPE ADDRESS FIELD 
USER DVXA EXAfiLE 0x5 BYTE R/l 



The fields of the user DVMA enable register are as follows: 

USEE DVMA EIABLE BECISTEX 

BIT KAKC KEAXIXC 

Entbl* Uatr DWA to CoDtazt 
Eai.ble U»*r DWA to Conttzt 1 
EnK.bl« Uttr DWA to Contazt 2 
Eaibl* U(«r DWA to Coatixt S 
En».bl« Uitr DWA to Conttzt 4 
En&bl* UBtr DWA to Context 5 
Eaa.bl» U»»r DWA to Conttzt 
En&blt Vft DWA to Contazt 7 



D<0> 


E».CXO 


D<i> 


El.CXl 


D<2> 


E».CX2 


D<3> 


EI.CX3 


D<4> 


EH.CX4 


D<5> 


Ea.CX5 


D<6> 


CX.CXS 


D<7> 


E3I.CX7 



When cleared after reset (see the chapter CPU Reset), all bits are initialized to 0. In this state, all user 
DVMA is disabled. 
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4.10. Bus Error Register 

When an error occurs during a CPU bus cycle to Control Space or Device Space whose cause is identified 
synchronously with the bus cycle, then that bus cycle terminates with a Bus Error signal, and the cause of 
the error is captured in the Bus Error register. The Bus Error register may also be written when 
coprocessor cycles in CPU Space time out, causing an unimplemented instruction exception (se€ below). 
However, no other bus cycles alter the Bus Error register. Tbb includes, in particular, DVMA cycles and 
other CPU Space cycles. 

The Bus Error register always "latches the cause of the most recent bus error for the CPU bus cycles 
indicated above. Thus, in the case of stacked bus errors, the information relating to the earlier bus errors 
b lost. 

The Bus Error register is a read-only register. 

Inltl&lizktloa: Voa* 



RECISTER/MAP A<31. 


,.28> 


D<1..0> 


SIZE 


TYPE 




ADDRESS 


Finj> 


BUS E2UU3R REC. 


OxA 




BYTE 


READ 








The fields of the Bus Error register 


are 


defined 


215 


follows: 




BUS ERROR REGISTER 
















BIT KAKE 




KEAXIRQ 













D<0> 


Unottd 




D<1> 


U&ai*d 




D<2> 


FPAEWERR 


FPA Eaublt trror 


D<3> 


FPABERR 


FPA bat trror rtiponi* 


D<4> 


VKEBERR 


VMEbnt Bui Error 


D<6> 


TIXEDUT 


TlBtoat Error 


D<e> 


PROTDIH 


Prot»ctlon Elrror 


D<7> 


IIVALID ■ 


larnlid Pig« 



In more detail, the bus error conditions are as follows: 

• FPAENERR is set, in implementations that support the Floating Point Accelerator, whenever 
the CPU attempts to access the FPA while its enable bit is reset (EN.FPA = 0). 

• FPABERR is set whenever the Floating Point Accelerator signals an error during a CPU bus 
access. The FPA has no interrupt capability; all errors must be reported as bus errors. 

• VMEBERR indicates that a CPU cycle to the VNlEbus was acknowledged with a VMEbus bus 
error. 

• TIMEOUT results from accessing non-existing devices, both on-board and off-board, during 
those CPU bus cycles which may record bus errors. For Sun-3 systems with caches, timeouts 
may abo result during Write Back cycles; these are reported through the Memory Error 
Control register, not the Bus Error register. All bus error timeout conditions are summarized 
below. 

• PROTERR indicates a protection violation resulting from an attempted access to a Device 
Space page during a CPU bus cycle. Protection errors resulting from cache accesses are 
discussed in the section "Definition of Cache Protection" in the chapter on the Sun-3 Cache. 
MMU protection errors arc detected during MNfU address translation. Two errors are possible. 
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First, an attempt to write into a valid page whose Write access bit is reset causes a 
PROTERR. Second, an attempt to access with User permission a valid page marked 
Supervbor access also causes a PROTERR. 

• INVALID means that the valid bit in the page map was not set during a CPU bus cycle to a 
Device Space page. 

Timeout errors, resulting from accesses to non-existing devices, may occur on CPU bus cycles to Control 
Space or Device Space. 

Control Space devices are decoded from fields of address bits; most devices are decoded from 
A<31..28>. Accesses to invalid codes within defined fields or to unimplemented Control Space devices 
will set the TIMEOUT bit in the Bus Error register. 

For accesses to Device Space, the treatment of CPU virtual address bits A<31..28> depends on 
whether the implementation supports the Floating Point Accelerator (FPA). In implementations that 
support the FPA, any Device Space accesses from the CPU in which virtual address bits A<31..28> *=» 
(0x1 through OxD) result in a TIMEOUT bus error. If the FPA is enabled (with EN.FPA = 1), accesses 
to a non-existing FPA also cause a TIMEOUT bus error. In implementations that do not supporl the 
FPA, A<31..28> are ignored. 

Other accesses to Device Space may cause timeout bus errors, as follows. Each implementation defines 
the size of its own Type physical address space. This address space includes main memory and (optional) 
frame buffers. Any Device Space access to either main memory or a frame buffer address space which is 
addressable, but not physically present, results in a TIMEOUT bus error. This may include, in particular, 
the Direct Access address space for the Copy-Mode frame buffer and the address space for the Video-RAM 
frame buffer. 

Sun-3 I/O devices are Type 1 devices identified by fields of address bits; most devices are uniquely 
identified by A<20..17>. Accesses to devices which are optional but not installed, or to invalid device 
codes within defined fields, result in a TIMEOUT bus error. 

Accesses to Type 2 or 3 Device Space (the VMEbus Master interface) may result in a TIMEOUT bus 
error if the addressed VMEbus device fails to respond within a defined time interval, which is specified for 
each implementation. 

4.11. Diagnostic Register 

The diagnostic register drives an 8-bit LED display for displaying error messages. A "0" bit written will 
cause the corresponding LED to light up, a 'l* bit to be dark. Upon power-on-rcset, the diagnostic 
register is initialized to causing all LEDs to light up. 
lnitit.ll2fclion: S«« cb^pttr on CPU Rtot 

RECISTEH/KAP A<31..28> D<1..0> SIZE TYPE ADDRZSS FIELD 



DIAC.nOSTlC REC. 0x7 BYTE VRITE 
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5. Device Space 



Device space includes all the devices of the system that are accessed through memory maoagcment. 
This includes main memory, video memory, the system bus, and input/output devices. 

In the following, each device is described in terms of its address, initialization, interrupts, exceptions, 
reference, and register mapping. 

Not all devices are present in all implementations of the architecture. The address assignment of all 
Sun-3 devices, however, is Hxed. Which devices are present are described in the implementation document 
for each machine type. However, the following devices are required for all implementations: 

o Main Memory 

• Memory Error Registers 

• Interrupt Register 

• EPROM 

• EEPROM 

• Clock 



5.1. Sun-3 Physical Address Map 

The Sun-3 physical address map is fixed for all implementations of Sun-3 architecture. In the map below, 
the Type code for each device and the base address (in 32 bit hex notation) for the device's address space 
are shown. 

The base address shown (below) for each device may be divided into address subficlds: one (or more) to 
identify the device and one to define the device's address space. 

Most Type 1 devices are uniquely identified by decoding physical address bits A<20..17>, but some 
devices may require the use of additional fields for unique device identification. Address bits outside 
defined fields are ignored on accesses to Type 1 devices in Device Space. Accesses to I/O devices which 
are optional to an implementation but not installed or to invalid device codes within defined fields are 
discussed in the Bus Error Register section. 

Type 2 and Type 3 spaces are VMEbus spaces. The size of the VMEbus address space is identified by 
decoding high order physical address fields. (A<31..24> = O.xFF) identifies the 24 bit field, and 
(A<31..16> == OxPFFF) identifies the 16 bit field. 

The number of physical address bits which define a device's address space depends on the MN'IU Type 
field and the implementation. The size of Type physical address space for main memory is 
implementation dependent. The size of the address space required for each Type 1 device varies according 
to the device. For Type 2 and 3 (VMEbus) devices, the 32 bit VMEbus address space excludes the top 16 
MB, and the 24 bit V?vlEbus address space excludes the top 64 I<B. 
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SUl-3 


PHYSICAL ADDRESS 


ASSICKtfEXTS 




TYPE 


PKYSTCAL BASE 
KbVKFSS 






DEVICE 


PHYSICAL 
ADDRFSS SPACE 




Vot«: Six* of 


Tjp. 





k^ldrtti tpkct la lBpltB»Dt&tio& <l«p»Dd*ct 





OxOOOOOOOO 






Ma,ln Mtftorx 


lapl. D«p«fid. 





0x00100000 






Kain-VaBorj FrtJi* Batfar 


A<16..0> 





OxOOlOOOOO 


- 


... 


— Copy-kodt Frwi« Buff»r - 
Copy Mod* acetic 


A<18..0> 





OxTFOOOOOO 






Copy-Mod* Fri«» Baffar - 
Dirvct &cc««c 


A<18..0> 





OxTFOOOOOO 






Vidto-RAM Trtm* Batftr 

« K^lBna: Minimna U A<17. 


A<20..0>» 
.0> ClBpl. d«p«nd.) 




Mot*: Tjp« 1 


d«Tlc«s 


id«ntlfl»d froB Addr»BS fitldi 


: ■•• vkch d«Tic* 




0x00000000 






K«ybo«rd/KoTi(« 


A<2..1> 




0x00002000 






Strlnl Port 


A<2..1> 




0x00004000 






EEPROM 


A<10..0> 




0x<?9p06000 






T1b« of Vxj Clock 


A<4..0> 




0x00008000 






MtBory Error R«g;l(t«rB 


A<2..0> 




OxOOOOAOOO 






Inttrrvpt Rtgittar 


(I byti) 




OxOOOOCOOO 






I&tal Etb*r&*t Inttrfxc* 


(I byt*) 




OxOOOOCOOO 






Color Map 


A<0..0> 




0x00010000^ 


■ 


— 


EPROM 


A<1B..0> 




0x00012000 






AID Etb«rii«t Int»rfa.c« 


A<1> 




0x00014000 






SCSI iDtvrfaca 


A<4..0> 




0x00016000 




^ 


(r«f«rT«d) 






0x00018000 






(r*(*rT»d) 






0x000 lAOOO 






(r«t«rT*d) 






OxOOOlCOOO 






Dtti Eicryptloa Proc. 


A<1> 




OxOOOlEOOO 




. 


ECC VtBory Rigi«t«ri 


A<7..0> 



Bota: Typ* 2 ipac* is WEbnt IB bit data tpac* 

AddrotB fialdi A<31..24> ud A<31..16> id«atify a.ddr«(« cpacat 



0x00000000 
OxFFOOOOOO 
OxFFFFOOOO 



V¥Eba« 32-bit addr«ft «pac« A<31..0> 
VlEbai 24-blt addrtis »pac« A<23..0> 
WEbat 18-bit &ddr*«a fpact A<1S..0> 



Vote: 7yp» S spa.c» ia WEbaa 32 bit data apa.ct 

Addraaa fivlda A<S1..24> and A<31..16> idtatify addraaa ap&caa 



OxOOOOOOOO 
OxFFOOOOOO 
OxFFFFOOOO 



V¥Ebua 32-bit iddrtaa apact A<31: .0> 
VlfEbaa 24-bit addraaa apica AC23,.0> 
VlCbaa le-blt addraaa ap&c* A<15..0> 



Iota: FPA ia Idtntifltd by dtcodlnj Vlrtoal Addrtaa bita A<31..28> 
M/A OxEDOOOOOO (Virtnal) Floiting Point Acc»l«rktor A<12..0> 
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5.2. Main Memory 

Main memory is the primary system memory. It is contiguous in physical addresses. The minimum siie 
is implementation dependent but is at least 2 Megabytes. The number of MMU address bits decoded to 
define the maximum physical address space is also implementation dependent. Sec the Bus Error register 
section on the handling of accesses to addressable but not-existing memory. 
Ibltiftlixfttloa: 6ott«&r« 



TYPE 


DEVICE ADDR 


DEVICE 


PHYS. SPACE 





CootisnoQt, 
vturtlftf at 


Uxin V»ftor7 


I»pl«B»nt&- 
tioa Dtptnd. 




ADD& 


REOISTKE 


DATA TYPE 







WJtUaT 


Lone READ-TOITE 



In most implementations, main memory b built from dynamic RAM chips. The dynamic RAMs arc 
refreshed in hardware. 

Main memory must be protected by either parity or ECC check bits. In both cases, the protection bits 
(parity or ECC check bits) must be initialized by writing memory before use. Errors detected in using 
memory are enabled and reported through the Memory Error registers, below. 

In implementations with ECC memory, the amount of memory data accessed in response to a CPU or 
DVMA bus cycle may be larger than required by the CPU or DVMA device. Memory errors detected in 
unused locations during the access may be reported to the Memory Error registers. 
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5.3. Frame Buffer: Data Organization 

Sun-3 implemcntatioDs may have no video memory, monochrome video memory, or color video memory. 
Monochrome video memory may be implemented using a main-memory frame buffer, a copy-mode frame 
buffer, or a video-RAM frame buffer. Color video memory must use the video-RAM frame buffer. 

Additional, external display devices and frame buffers can be added to those implementations of the 
architecture that include a system bus. These external frame buffers arc not within the scope of this 
document. 

There are two data organizations, for Sun-3 video memory: one for monochrome and one for color. The 
data organization determines how video memory data are displayed on the screen. 

The data organization for monochrome video memory is as follows. Data bit 15 of Word of the frame 
buffer is the first visible pixel in the upper left corner of the display. Consecutive words are displayed 
along the horizontal scanline left to right. After < display -width> number of pixels have been dbplaycd, 
the next word is dbplayed at the beginning of the next horizontal line, up to <display-height> number of 
lines. <display-width> and <display-height> are implementation constants. The display data polarity 
b such that "l" bits are black on the screen and •0' bits are white. 

8 » <dlflplK7>«idtK> / 18 

M « <dl«plfcy-htljht> 



16 



16 



15 



16 



1 TORD 


1 VORO 1 


I .. 


1 


WORD I-l 1 


1 VORO 1 


1 VORO n*i 


t .. 


1 


; TORO 2»M-1 1 


1 ... 


I ... 


1 .. 


1 


1 ... 1 



I TORO (H-1)»I I 



I 



I fORD B»K-1 I 



The data organization for color video memory is as follows. Each byte of video data corresponds to one 
display pixel. A color map, which is a Type 1 device described elsewhere, translates the byte into the 
display pixel. Each bit within the byte corresponds to a memory plane; eight planes are supported. By 
convention, bit refers to plane 0, bit 1 to plane 1, etc. * 

The high order byte in color video memory maps to the first visible pixel in the upper left corner of the 
display. Consecutive bytes are displayed as consecutive pixels along the horizontal scanline left to right. 
After <display-width> number of bytes are mapped to pixels, the next byte maps to a pixel displayed at 
the beginning of the next horizontal line, up to <display-hcight> number of lines. <display-width> and 
<display-height> are implementation constants. 

K a <di«plky-Tldth> 



7 



I BYTE 0=>P1X I BYTE I 



I BYTE B=>PIX I I BYTE I*l 



7 



I .. 



I BYTE (M-O'I I 



1 .. 



7 



I BYTE H-1 

I BYTE 2»«-i 

I 

I BYTE M»H-1 
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5.3.1. No Frame Buffer 

If there ia no frame buffer, then the Video Enable Bit and the Copy Enable Bit of the System Enable 
Register arc not used. 



5.3.2. Main-Memory Frame Buffer 

Id this alternative the frame buffer is resident in main memory and the video display is refreshed out of 
main memory. 

The visible display area starts at main memory address 1 megabyte and extends to the size of the 
display. The maximum size of the visible dkplay area b 128 kilobytes. 
Initialization: Softv&r* 
Intarrnpt: L»t«1 4 Antovactor 



TYPE 


DEVICE ADDR DEVICE 


PHYS. 


SPACE 





0x00100000 Main-KaBorj Frui* Dtr 


A<16. 


.0> 










AODR 


REGISTEft DATA TYPE 







0x00100000 FB 0x00000000 LOHC READ-fRITE 
OxOOUFFFC FB 0x000 IFFFC UIHG EEAD-IRITE 

The only relevant bit in the System Enable register is the Video Enable bit, which turns the display on 
and off. The Copy Enable bit has no effect. 

5.3.3. Copy-Mode Frame Buffe ' 

In this configuration, the frame buffer is lot ted in a dedicated 128K byte video memory. This video 
memory is dual ported: one port performs vide refresh, and the second port provides processor access. 
Initialization: Soft*ar« 
Inttrrapt: L«v«l A AutoT«ctor 



TYPE DEVICE ADDR DEVICE PHYS. SPACE 



0x00100000 Copy-Bod» Fraat Btr - A<16..0> 

Cop7 Vod« accttt 
OxfTOOOOOO Copj^Ioda Fra«« Bfr - A<10..0> 

Dirvct acc*«a 



ADDR REGISTER DATA TYPE 

OiOOlOOOOO or FB OxOOOCOOOO LOHC READ-TRITE 

OxJT 000000 

OxOOUFFFC or FB OxOOOlFTTC LO»C RE\D-»RITE 

OxJTOlFTFC 



Relevant bits in the System Enable register are the Video Enable Bit and the Copy Enable Bit. The 
Video Enable bit turns the display on and off. The Copy Enable bit enables the copy mode (see below). 
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The video memory can be updated in two ways. First, it can be read and written directly, like memory. 
As such, it is vbiblc as a 128 KByte block of memory locations starting at address OxFFOOOOOO. Second, 
the video memory can be written in copy mode aa a side effect of writing into a special region of main 
memory. This region starts at address 0x00100000. 

Main memory shadows video memory in the range of physical addresses starting at 1 megabytes and 
extending for 128 kilobytes. This area of main memory is called the copy region. If the copy enable bit in 
the system enable register Is set, then data written into this copy region is also written into the video 
memory at the same location within the 128K region. A read from the copy region returns data from the 
main memory and does not affect the video memory. 

Note that the physical main memory and the Direct Access address space for the Copy-Mode frame 
buffer need not form a contiguous address space. If the Copy-Mode frame buffer b unjmplcmented, an 
attempt to access the Direct Access address space may result in a bus error. See the Bus Error register 
section for details. 



5.3.4. Video-RAM Frame Buffer 

In this configuration, the frame buffer is located in a dedicated area of memory which is dual ported: one 
port performs video refresh, and the second port provides processor access. The'size of the Video-RAM 
frame buffer varies by implementation, in 256 KB increments, from 256 KB minimum to 2 MB maximum. 

Initi&llz&tion: Softvura 
InttrrTipt: LtT«l 4 AntoTtctor 



TYPE 



DEVICE ADDR 



DEVICE 



PHYS. SPACE 



OxFFOOOOOO Vld«o-RAM Fri.»» Bfr A<20..0>» 

• MuiBQi: KiniiTia !• A<17..0> (Ispl. daptnd.) 



ADDR 

OxFFOOOOOO 

OxFFlFFFFC» 



REGISTER 



DATA TYPE 



FB 0x00000000 LOHC READ-TRITE 
FB OxOOlFFFFC* LOHC READ-fRITE 
* Addrtta for 2 KB DiixinTia 



The only relevant bit in the System Enable register is the Video Enable bit, which turns the display on 
and off. The Copy Enable bit has no effect. — 

The video memory is updated by reading and writing it directly, like memory. Note that the physical 
main memory and the address space for the Video-RAM frame buffer need not form a contiguous address 
space. If the Video-RAM frame buffer is unimplemented, an attempt to access its address space may 
result in a bus error. See the Bus Error register section for details. 



Sun Nlicrosystcms Inc 



CONFIDENTUL 



IG May 1985 



SuD-3 Architecture Rev 2.0 Prelim 



Device Spjtce 



n 



5.4, Color Map 

The Color Map maps bytes in color video memory into display pixels. It contains three 256 byte 
sections: one each, for red, green, and blue. 
Initlk.llsiktio&: Softwfcr* 
I&tarmpt: L*t«1 4 Aat«T«ctor 



npE 


DEVICE ADDR DCVICS 




PHYS. SPACE 


1 


OzOOOOEOOO Color lap 




A<0..0> 




AODR 


RECISTLR DATA 


TYFE 


' 



0x000 



BED HAP DzOO BYTE 



READ TOITE 



Oxorp 


RED MAP OxTP 


BYTE 


READ WRITE 


0x100 


CRFm MAP 0x00 


BYTE 


READJTRITE 


OxlFP 


CREta MAP OiPP 


BYTE 


READ ¥RITE 


0x200 


PJJUE MAP 0x00 


BYTE 


READJTRITE 


0x2rp 


BTJJE MAP OxPF 


BYTE 


READ_fRITE 



The Color Map is generally written during vertical retrace. Following the assertion of a Level 4 interrupt 
for the color map, the map update must complete within 600 microseconds (the vertical retrace time) to 
avoid being visible in the display. Longer updates will complete but the display appearance may be 
affected. 
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5.5. Memory Error Registers 

All Sun-3 implementations have either parity memory or error correcting (ECC) memory. ECC memory 
corrects (and optionally reports) single bit errors, and it detects and reports double bit errors. Errors 
detected in both versions of memory are reported with the Memory Error registers described m this 
section. In addition, other errors resulting from Sun-3 cache operations are abo be reported in the Memory 
Error registers. 

The Memory Error registers consist of a control and an address register. If an error occurs, the control 
register stores information relevant to the error, and the address register freezes the virtual axldress of the 
bus cycle in error. 

Errors are reported via the non-maskable level 7 interrupt. In case of multiple (stacked) memory errors, 
the information relating to the first error b latched in the memory error registers. The interupt b held 
pending and the error information in both memory error registers b latched (frozen) until it b cleared 
(unfrozen) by a write to bits <31..24> of the Memory Error Address regbter. This write does not affect 
the enable bits D6:D4 of the Memory Error Control regbter. Dbabling the PARITY CHECK bit in the 
Memory Error Control regbter for parity memory also clears the interrupt and error information. Finally, 
Power On and Watchdog resets clear the entire Memory Error Control register. 

Iaitii.lizktion: S«» chk.pt«r on CPU R«*tt 

latarropt: L«Tal 7 Aotoractor 



TYPE 


DEVICE M>Da 
(D»cod« A<20..17» 


DEVICE PHYS. SPACE 


1 


0x00080000 


■•Borj Error A<2..0> 
R«gi«ttrt 








ADDR 


REGISTER 


DATA TYPE 




4 


MEMORY E31R0R CORTROL 
MBTORY ERROR ADDRESS 


BYTE READ-tRITE 
LOKC R£AD-01fLY 



The memory error address register freezes the virtual address, the context number, and a DVMA/CPU 
identifier of the memory bus cycle in error. For implementations with ECC memory, the Memory Error 
Address register does not record the failing address on Correctable Errors (bit D<0> of the Memory 
Error Control register). The physical addresses for CE's are captured in the Correctable Error register on 
each memory board. (See the section 'The Correctable Error Register" in the chapter on ECC Memory.) 

KEXORY EJIROR ADDRESS REGISTER 



BIT MAKE TYPE KEAWISG 



D<27..00> VA<27..00> rtkd-only Virtual Addrm (28 bit) 

D<30..2a> CX<2..0> r«kd-onl7 Contort Honbtr (S bit) 

D<31> DV^IA-BIT r»»d-only DVKA cycl« •rror 

The control regbter has two formats, one for parity memory and one for ECC memory. The two 
formats arc structured similarly: D<3..0> record the type of error, D<6..4> are enable bits, and D<7> 
is tlic interrupt bit. The control register for ECC memory records both ECC errors and errors resulting 
from Sun-3 cache operations (if implemented). ~ 
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5.5.1. Error Control Reg for Parity Memory 

For systems equipped with parity main memory, the memory error cootrol register provides the 
necessary control and inTormation to deal with parity errors. 

It stores the information on the byte(s) causing the parity error, sets a pending parity error interrupt, 
and provides functions to test parity error checking. 



IfEXORY ERROR CONTROL REGISTDl tor Purity Ktaorj 

BIT . HAKE TYPE . KEUIKG 

0<O> PARITY E31R0R 00 rtfcd-only Parity Error, bit* D07:D00 

D<1> PARITY ERROR 08 r»»4-oaly Pxrlty Error, blt« D16:D08 

Jf D<2> PARITY ERROR 16 r»»d-only Parity Error, bit* D23:D16 

'ip<i> PARITY ERROR 24 r»kd-oaly Parity Error, blti D3l:D24 

I D<4> PARITY CHECX r**d-»rlt« Eaabl* parity cbtcklnj 

' D<B> PARITY TEST r»ad-writ» T»»t by Invarting parity 

VD<6> PARITY IMT EffBL r»a«l-»rlt« Parity lattrrnpt tnabl* 

f D<7> PARITY IHTRPT r»ad-oaly Parity inttrropt (1«t«1 7) 



c 



• The four parity error bits are set when a parity error b detected in the corresponding byte. 

• Parity check is set to enable parity checking on memory read cycles. 

• Parity test is set to write parity with the inverse polarity to test the operation of the parity 
error circuitry. With parity test off, correct parity is generated on all memory write cycles. 

• Parity interrupt enable enables level 7 interrupts if a parity error is detected, 
o Parity interrupt is true if a parity interrupt is pending. 

5.5.2. Error Control Reg for ECC Memory 

For systems equipped with ECC main memory, the Memory Error Control register provides the 
necessary control and information to deal with both cache related and ECC errors. 



VTVORY 


ERROR COHTROL REGISTER for ECC 


V«Bory 


BIT 


BAJCE 


TYPE 


KEUIXG 


D<0> 


CE 


rtad-only 


Corr«ctabl« Error 


D<1> 


UE 


r«ad-o3ly 


Uacorrtctabl* Error 


D<2> 


WEACKERR 


r«ad-only 


frit* Baclc trror 


D<3> 


VB TIKEDUT 


r«ad-only 


Brit* Back cyclt tlat out 


D<4> 


ESABLE CE 


r»ad-*rit» 


Elnabl* CE rtcording 


D<B> 


EUSHDLO 


r»»J-*rit» 


Hold a*Borj ba* Kiicttrchip 


D<6> 


EKABLE IBT 


rtad-Brlt« 


Enabla trror iat.«rraptg 


D<7> 


ERROR 1»T 


r«ad-oBly 


Elrror interrupt 



• The CE bit records a correctable error. It functions somewhat differently from other error bits' 
D<3..1>. If enabled by the ENABLE CE bit D<4>, the CE bit is set if the ERROR 
STATUS bit D<0> of the Correctable Error Reg on ANT memory board is active (indicating 
a CE on that board). It resets only if ALL Error Status bits are reset. In particular, resetting 
the Memory Error Register by writing to the Memory Address Register docs NOT reset the 
CE bit. (See abo the section 'The Correctable Error Register* in the chapter on ECC 
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Memory.) 

• The UE bit records an Uncorrectable error. 

• WBACICERR is set whenever there is a translation exception during a Write Back bus cycle 
for implementations with a cache. See also the section "Cache Error Conditions* in the Sun-3 
Cache chapter. 

• The WB TIMEOUT error bit is set whenever a bus time out is detected on an Write Back bus 
cycle for implementations with a cache. Write Back cycles are asynchronous with respect to 
CPU and DVMA bus cycles. See also the section "Cache Error Conditions" in the Sun-3 Cache 
chapter. 

• The address captured in the Memory Error Address regbter for WBACK and TIMEOUT 
errors is that of the cache block which caused the error. 

• ENABLE CE enables the recording of a Correctable error as bit D<0>. 

• The BUSHOLD bit causes the CPU board to retain memory bus mastership for those 
implementations that support a multi-master memory bus. 

• ENABLE INT enables an interrupt to the processor (bit D<7>) for any of the error 
conditions D<3..0>. 

• The ERROR INT bit signals a level 7 interrupt to the processor. 

The Memory Error Address register acts in conjunction with the Memory Error Control register for 
ECC memory to freeze the failing virtual address for all error conditions recorded in Error register bits 
D<3..1> (not CE's). The physical addresses for CE's are captured in the Correctable Error Reg on each 
memory board- 
On WBACKERR and WTB TIMEOUT errors, the failing virtual address is that of the former cache entry 
being written in the Write Back bus cycle. The DVMA-BIT, D<31> of the address register, is set to 0. 



Sun Microsystems Inc CONFIDENTIAL IG Mriv 1985 



Sun-3 Architecture Rev 2.0 Prc!im Device Space 20 

5.6. Clock 

The timer is an Intersil 7170 time-of-day clock with battery backup. The timer crystal has a frequency 
of 32.7C8 kHz. It is expected that the clock interrupt output b driven in the 100 Hx periodic mode. This 
clock interrupt output signal causes an interrupt request on level 5 or 7 via the interrupt register, if the 
respective levels arc enabled. 

laivrrnpt: L«t«1 5 or 7 EvtoTcctor 

InltiallxktloB: Ion* 

R*f*r«Bc»: InUrill 7170 D^t^ Sh*»t, 



TYPE 


DEVICE ADDR 

(Dacod* A<20..17» 


~' DEVICE 


PHYS. SPACE 


1 


Ozoooeoooo 


TU« of 


Daj Clk A<4..0> 




ADDR 


RraisTza 


DATA 


TYPE 



OjcII 


CLOCK RIjS 0x0 
CLOCX R£C 0x11 


BYTE 
BYTE 


READ-WRITE 
READ-tRITE 
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5.7. Interrupt Register 

The interrupt register provides for the generation of software interrupts and controls the video and clock 
hardware interrupts on the board. It has the following fields: 

Inltiftlixwiloa: S«« ch»pt«r on CPU R«t*t 
Interrupt; Ltttl 1,2,S,4,B,7» mtoTtctor«d 



TYPE 


DEVICE ADDR 
(Dicodt A<20..17» 


DEVICE PKYS. SPACE 


1 


OxOOOAOOOO 


— Inttrrnpt Rag (I bjt») 




ADDR 


REGISTER 


DATA TYPE 





IHTERRUPT REGISTER 


BYTE READ-TOITE 




IMTERJUJPT REGISTER 


BIT 


MAME TYPE 


KEAXIIG 



D<0> 


EK. 


IMT 


r«i.d-nrril» 


D<1> 


EJI. 


IBTl 


rtfcd-»rlt# 


D<2> 


EH. 


,IHT2 


r««.d-*rlt« 


D<3> 


EX. 


.IRTS 


r«»d-»rltt 


D<4> 


EK, 


.IKT4 


r»i.d-wrlti 


D<5> 


E3I, 


.IHT5 


r«i.d-¥rlt» 


D<6> 


EH, 


.IKTfl 


rtid-writ« 


D<7> 


El. 


Ann 


r««.d-»rlt« 



E&abl« &11 IstarrTipts 
Soft*t.r« Inttrropt L«t«1 1 
Sottv&rt Interrupt L*Ttl 2 
Softv&r* IcttrrTipt L«t«I S 
En&blt Vldvo I&trpt L«t1 4 
Efiibla Clock Intrpt L«t1 5 
Cr«BarT«d) 
En&bl* Clock Intrpt L«t1 7 



EN. INT. This bit enables all interrupts. If this bit is off, no interrupts will occur. 

EN.INT<3..1>. These bits cause software interrupts on the corresponding level. The interrupt request 
caused by an EN.INT<3..1> bit stays active until software clears the corresponding bit. 

EN.INT4 enables video interrupt requests on level 4. When enabled, a level 4 interrupt request is set at 
the rising edge of vertical retrace. The level 4 interrupt request is cleared by momentarily turning off the 
EN.INT4 bit. This bit has no effect in implementations which have no memory frame buffers. 

EN.INT5 enables clock interrupt requests on level 5. When enabled, a level 5 interrupt request is set on 
the rising edge of the clock interrupt output. The level 5 interrupt request is cleared by momentarily 
turning off the EN.1NT5 bit. 

EN.INT6 is a reserved bit. It can be read and written but has no effect. 

ENJNT7 enables clock interrupt requests on level 7. When enabled, a level 7 interrupt request is set on 
the rising edge of the clock interrupt output. The level 7 interrupt request is cleared by momentarily 
turning off the EN.INT7 bit. 
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5.8. EPROM 

The EPROM device consists of one 27128, 27256, or 27512 type EPROM providing 16K, 32K, or 64K 
bytes of PROM storage, respectively. 
I&iti».lisktlo&: KoD* 
IntvrrTipt: Ron* 

R*f*r«Bc«: Ion* 



TTPE 


DEVICE ADDR 
(D»cod« A<20. 


.17» . 


DEVICE 


PHYS. 


SPACE 


1 


0x00100000 




EPROM 


A<16. 


.0> 




ADDR 


REGISTEA 




DATA 


TYPE 





1 


EPROM BYTE 
EPROM BYTE 1 




BYTE 
BYTE 


READ-OlfLY 
READ-OILY 





Unlike other devices, the EPROM b addressed directly with virtual address bits from the CPU. Thus, 
even though each 8K page of EPROM data must be enabled with its own entry in the page map, the 
translated address bits A<15..13> from the MMU are ignored. The EPROM b addressed instead with 
address bits A<15..0> (for 64KB) from the CPU. 

The EPROM device b also accessed in boot state. In boot state, all supervisor program fetches are 
forced to fetch from the EPROM device, independent of the setting of the memory management. 



5.9. EEPROM 

The EEPROM device consists of one 2816 type EEPROM providing 2K Bytes of electrically erasable 
storage. 

I&iti&liz&tlon: Xon* 
Int»rrnpt: Hon* 
R«f«r«nc*: Bo&» 



TYPE 


DEVICE ADDR 
(Dtcodt A<20..17» 


DEVICE 


PHYS. SPACE 


1 


0x00040000 


EEPROM 


A<10..0> 










ADDR 


RFEISTER 


DATA 


TYPE 




1 


EtPROM BYTE 
ELPROX BYTE 1 


BYTE 
BYTE 


READ-¥R1TE 
READ-IRITE 



To modify the EEPROM, each byte must be written separately. After writing each byte Software must 
guarantee at least a 10 millisecond pause before the EEPROM can be read or v/ritten again. 

Bytes can be read successively with no delays. 
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5.10. Serial Port 

Serial ports are implemented with the Zilog 8530 SCC (Serial Communication Controller). The SCC 
features two high-speed, fully symmetrical and highly programmable serial channels with built-in baud- 
rate generators. Channel A is connected to the UART A, channel B to UART B. The clock input to the 
SCC b a 4.9152 MHz clock, independent of the CPU clock. 

Software must guarantee the device recovery time of 1.6 microseconds. 

The SCC is mapped as follows: •• 

lattrropt: — L«t«1 6 V«ctortd (praf»rr»d) or AutoT»ctor»d 
iDitialls&tioa: S«» ch&pt«r on CPU R«>«t 
Rafara&c*: Zllof 6630 SCC iktk. thttt 
RtcoTtry lis*: 1.0 Bicroftco&df 



TYPE 


DEVICE ADDR 
(Daeodt A<20. 


.17» 


DEVICE 




PHYS. 


, SPACE 


1 


0x00020000 




S»rl».l 


Port 


A<2., 


.!> 






ADDR 


REGISTER 




DATA 


TYPE 









2 

A 
6 


CH B COITRQL 
CH B DATA 
CH A COITRflL 
CH A DATA 




BYTE 
BYTE 
BYTE 
BYTE 


RZAD-TOITE 
READ-TOITE 
READ-TO I TE 
RZAD-TOITE 







5.11. KeyboEird/Mouse UART 

These serial ports are implemented with the Zilog 8530 SCC (serial communication controller). The 
SCC features two high-speed, fully symmetrical and highly programmable serial channels with built-in 
baud-rate generators. Channel A b connected to the Keyboard, channel B to the mouse. The clock input 
to the SCCs is a 4.9152 MHz clock, independent of the CPU clock. Control lines are not used. 

Software must guarantee the device recovery time of 1.6 microseconds. 

The SCC b mapped as follows: 

Intarrcpt: L»t»1 & Vactorad (prtfarrad) or AntoTactored 
Initi&lizatloB: Saa cbaptar on CPU Raaat 
Rafaranca: Zilog 6530 SCC dat& ahaat 
RacoTary Tiaa: 1.6 ■Icrosaconds 



TYPE 


DEVICE ADDR 
(Dacoda A<20. 


.17» 


DEVICE 


PHYS. SPACE 


1 


OiOOOOOOOO 




Kajboxr 
UART 


d/MoTifa A<2..1> 












ADDfl 


REGISTER 




DATA 

BYTE 
BYTE 
BYTE 
BYTE 


TtPt 



2 

4 
6 


CH B COKTROL 
CH B DATA 
CH A COHTRCL 
CH A DATA 




READ-miTE 
READ-TOITE 
PJ>.D-TOITE 
READ-TOITE 
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5.12. Encryption Processor 

The Encryption processor is an AMD 8068 data ciphering processor providing high-speed NBS DES 
encryption. To access an internal register in the 80G8, the address register must be v^rritten first. Once the 
address register is setup, the selected register can be accessed repeatedly. 

Iaitia.llx»tioa: loa* 

Int*rr«pt«: loa* 

R«t«raDc«: AKD 8060 d*.\.%. tbatt. 

RacoTtry TiB«: 1.6 aicrotaco&da 



TYPE 


DEVICE AODR 
(Dtcod* A<20.. 


17» 


- DEVICE PHYS. SPACE 


1 


OxOOlCOOOO 




D»ta Encryp- A<1> 
tioa Procatsor 




ADDR 


RTCISTER 




DATA TYPE 




2 


DATA REGISTER 
ADDRESS REGISTER 


BYTE READ-WRITE 
BYTE WRITE-OILY 
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5.13. AMD Ethernet Interface 

The AMD Ethernet Interface uses the 7990 chip for DVMA transfers. In its maximum DVMA 
configuration, the 7990 accesses the top 16 Megabytes of the current virtual address space with a 
supervisor data function code. (See also the chapter on DVMA Devices.) The 7990 must be configured in 
BCON=0 mode in its CSR register. 

The 7990 must access physical memory in TYPE space only; bus cycles to non-existing memory or to 
non-Type space will not complete, and the 7990 will post a timeout error. The 7990 can also post a 
timeout error because of a protection error. Neither error b reported to the CPU. Memory errors (either 
parity errors or uncorrectable errors) on read operations are not reported to the 7990 but are reported 
only to the CPU, as interrupts through the Memory Error registers. 

Initialisation: St* chk.pt*r on CPU R«t«t 

Inttrroptt: L*t»1 S. Antoractor 

K*f»r«nc«: AXD 70DO da.tt. «h««t. 



TYPE 


DEVICE ADDR 
(Ovcod* A<20. 


.17» 


DEVICE PHYS. SPACE 


1 


0x00120000 




AKD Etb«rn»t A<23..0> 
Inttrf&c* 










ADDR 


REGISTER 




DATA TYPE 



2 


DATA PORT 
COHTROL PORT 




fORD READ-TO I TE 
TORO RZAD-TOIIE 



5.14. Intel Ethernet Interface 

The Intel Ethernet Interface uses the Intel 82586 chip for DVMA transfers. In its maximum DVMA. 
configuration, the 82586 accesses the top 16 Megabytes of the current virtual address space with a 
supervisor data function code. (See also the chapter on DVMA Devices.) 

The 82586 must access physical memory in TYPE space only; bus cycles to non-existing memory or to 
non-Type space will not complete, but will set the ERR bit D<1> in the Ethernet Control regbter. 
Other conditions which set the ERR bit include a protection error or a memory error (either parity error 
or uncorrectable error) on read operations. 

Once the ERR bit is set, Sun-3 implementations of the Intel Ethernet Interface must inhibit further 
Ethernet transfers until the RESET* signal in the Ethernet Control register b asserted (RESET* = 0). 

The 82586 b connected to the system in a permanent byte-reversed mode; that is, within each word, 
82586 bits through 7 are mapped to MC68Q20 bits 8 through 15, and visa versa. This causes Ethernet 
data to be stored in memory in CPU byte order, whereas 82586 control blocks in memory are byte 
swapped. 
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Overall operation of the Ethernet Interface b controlled by the Ethernet Control register, which haa the 
following definition. 

lDlti%liz&tlo&: Sft« chfcpttr oa C?U R»i«t 
lotarrnpta: L«t«1 S, Aatovcctor 
R«f*r«QC«: I&ttl 8258& data ib»*t. 



rfFE 



DEVICE ADDR 
(D»cod» A<20..17>) 



DEVICE 



PHYS. SPACE 



1 OxOOOCOOOO 


Inttl Eth*rn«t A<23. 
I&t«rf»c« 


.0> 


. 


ADDR REGISTDl 


DATA TYPE 




coiiani. RECisiEa 


BYIE READ-WRITE 




he fields of the Ethernet control 


register are assigned 


as follows: 


ETHERMET COHTROL REGISTER 


BIT lAHE TYPE 


KEAIIXG 





D<0> 


IIT 


rtfcd-only 


InttrrTipt P^udinj 


D<1> 


ERR 


rtid-oaly 


Error Pending 


D<2> 





r« id-only 





D<S> 





rtfcd-only 





D<4> 


IITEI 


r«ikd-»rlt« 


Ittt«rnipt Enable 


D<B> 


CA 


r»i.d-»rlt« 


Chunal Attt&tion 


D<C> 


LOOFB* 


r«a4-»rit» 


Loopb&ck 


D<7> 


RESET* 


r«»^-»rlt» 


R«f*t 



/NT signals Interrupt from the 82586 or an error pending condition (ERR=1). 

ERR indicates that a Bus Error occured during an 82586 channel operation, inhibiting further channel 
activity. To reset the ERR condition, the RESET*" bit must be set active (RESET* = 0). 

RESET bit in the Ethernet control register must be activated. 

/ATEiV enables 82586 interrupts to the CPU. 

CA signals channel attention to the 82586. 

LOOPB* controls whether the front-end encoder/decoder is configured in loopback mode (LOOPB* = 
0) or connected to the transceiver cable (LOOPB* = 1). 

RESET'^ initializes the 82586 when active (RESET* = 0) and allows normal operation when inactive 
(RESET* = !)• It also clears the ERR condition when active. 
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5.15. SCSI Interface 

The SCSI interface provides DVMA access to Type space and supports programmed I/O accesses from 
the CPU. In its maximum DVMA configuration, SCSI accesses the top IG Megabytes of the current virtual 
address space with a supervisor data function code. (See also the chapter on DVM.\ Devices.) 

The SCSI Control logic uses two addressable VLSI devices: the NCR 5380 SBC (SCSI Bus Controller) 
and the AMD 9516 l^DC (Universal DMA Controller). The 5380 SBC b a byte oriented chip which 
implements disconnect/reconnect and has high-current drivers allowing it to be connected directly to the 
SCSI bus. To minimize the memory bandwidth requirement, byte-to-word packing is done with external 
logic, and the packed words are transferred to memory under control of the 9516 UDC. An 8 KB FIFO 
queue between the SCSI Bus Controller and the DMA Controller buffers packed SCSI data to improve 
performance. 

For additional information on these chips, consult the appropriate data sheets. 



5.15.1. SCSI Addressable Devices 



The following addressable devices are implemented in the SCSI Control logic: 
iBtarrapt: L«t«1 2 Autoractor 

InitifclizLtlon: S«« cha.pt«r ob CPU R«««t 



TYPE DEVICE ADDR 

(Dacod* A<20..17>) 



DEVICE 



PKYS. SPACE 



1 


0x00140000 


SCSI Iat»rfiic» 


A<23..0> • 










ADDR 


REGISTER 


DATA 


TYPE 



A<4..0>='00iiaa' SCSI BUS CCHTROLLER BYTE READ-fRITE 

A<A..l>='100n* UMIVDISAL DJUl CUTLR tORD READ-TRITE 

A<4..1>='1010* FIRSTBYTE REG TORD READ-OKLY 

A<*..1>*'1100' SCSI STATUS REC . TORO READ-TOITE 

loti: *&* indic>.t*a bits d»cod»d bj tb» cbip 

The SCSI Status register provides control and status information. Bits to 3 are writeable and are 
cleared by system reset. Bits 9 to 15 are read-only and provide status information. The Firstbytc 
register, used with the Status register, records the leftover byte in an odd length transfer. 
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SCSI STATUS RECISTEX 



BIT 



RAlOt 



TYPE 



KEAIING 



D<0> 


SCSI RES- 


rt td-vrit« 


SCSI R*s»t (Ninas &ctlT«) 


D<1> 


nro RES- 


VtA-tTitt 


FIFO R*i«t (ItlDut nctlTv) 


D<2> 


SBC iiT a 


r«»d-»rlt» 


SBC Intarrupt En&bl* 


D<S> 


SEBD 


rtKl-nrlt* 


S«&d d&ta to disk 


D<4..8> 


Uaotad 


r»i.d-oal7 


R*a4l bick %B 0'« 


D<0> 


SBC IIT 


r«ul-oaly 


SBC lutarrapt p«Ddi&f 


D<10> 


FIFO EXFTt 


r«i4-only 


FIFO tapty 


D<11> 


FIFO FULL 


r»i.d-only 


FIFO lull 


D<12> 


SECOJJDBYTE 


r«»4-only 


S«coDd byt« 


D<13> 


SCSI B£R& 


r«»4_P'il7 


SCSI bat arror 


D<14> 


SCSI BCWFL 


r«wi-only 


SCSI bnt conflict 


D<i5> 


XFR ACTIVE 


r»Kl-only 


Trmtftr kctli* 





FIRSTBYTE REGISTER 


BIT 


lAKE 


TYPE 


KEASIHG 


D<0..7> 
D<8..15> 


U&Qiad 
LAST BTYE 


r«»d-only 
rtt4-only 


Unattd d&t& bjt* 

La.st byt*. un»ll^»d xtr 



• SCSI_RES- (minus active) resets both the 5380 SBC and the 9516 UDC during system reset 
and should be asserted in case of SCSI_BERR or SCSI_BCNFL errors. 

• FIFO__RES- (minus active) initializes the FIFO controls and should be asserted when the 
SEND direction is established or after SEND has been established. 

• SBC_INT_EN gates the interrupt output from the 5380 SBC onto auto-vector interrupt 
level 2. 

• SENT) indicates the direction of data transfer is to the disk. 

• FIFO_EMPTY and FIFO_FULL indicate the state of the fifo buffer. 

• SECONDBYTE indicates that an odd number of bytes were transferred on the SCSI bus. 
Since DVMA transfer is by words, the leftover byte needs to be read from the Firstbyte 
Register bits 8 to 15. 

• SCSI_BERR indicates that an error occured during a DVMA cycle to memory. Possible 
errors include translation errors, protection errors, accesses to addressable but unimplemented 
memory (Type space) or non-Type space, and memory data errors (parity or uncorrectable 
errors). 

o XFR_ACTP/E indicates that the 5380 SBC is actively transferring data on the SCSI bus. 
The cpu should not attempt to access the SBC during this time. If it should do bo, 
SCSI BCNTL will be set. 
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5.15.2. SCSI Programming Guide 

The 5380 SDC can be programmed for either DVMA or programmed 10 transfer. If programmed lO is 
used, the 9516 UDC should be programmed off and FIFO_RES- asserted (negative). To use DVMA. the 
6380 SBC must be programmed for "non-block DMA' mode. The 5380 SBC can be programmed to 
interrupt at level 2 on any of the following conditions: 

- ••l»ctiosL/r«»»l«ctioa 

- EDP ( not u««d ) 

- SCSI bufl r»t*t 

- SCSI but ■•Borj •rror ..._ 

- Bnt pbt.i« miiBatcb (c.f. &t tb« tod of SCSI da.tK. tr&&tf«r) 

- loas ot SCSI bag BSY ■Ign&I 

For DVMA transfers.the 9516 UDC must be programmed to the 'flyby transaction, single operation* 
mode. All DVMA transfers are done in word mode. The UDC generates a 24 bit address in the master 
mode and contains 2 channels, of which only channel 1 b used. The UDC can be programmed to 
interrupt at level 2 on any of the following conditions: 

- p&tt»rn Bitcb C not xisvd ) 

- EDP 

" chk.in B.bort«d 

The EOF interrupt can be generated either internally on a terminal count or externally if SCSI__BERR 
or SCSI__BCNFL occurs. Chain-aborted interrupt referrs to the UDCV auto-chaining operation, which 
allows the UDC to use DMA to transfer from memory all the words needed to initialize its internal 
registers. The processor need only supply the UDC with the starting address of the auto-cbain memory 
block. 

Several registers internal to the UDC are described as slow-readable, meaning they take 2 microseconds 
to read. THese are the pattern register, the mask register, interrupt vector register, and channel mode 
registers. The slow-readable registers are not accessible in the Sun-3 implementation and attempts to read 
them will return unknown data. Another peculiarity of the UDC is that commands to it must be 
separated by 4 UDC clock cycles; the UDC clock rate is implementation dependent. This requirement will 
be a software responsibility. 

The 8K FIFO bused to buffer DVMA disk transfers. It takes about 16 ms for the disk to transfer 8K 
bytes, and about 4 ms for DVMA to fill or empty the FIFO, depending on the implementation clock rate, 
the DVMA controller, and other memory activity. The disk and DVMA operations can be concurrent. 

5.15.3. SCSI FIFO Testability 

To verify that all 8K bytes of the FIFO buffer are reading and writing properly, the disk side of the 
FIFO must be dbablcd so that no data is transferred to the disk. (Thb can be done by programming the 
5380 SBC chip to not transfer data,) To fill the FIFO, the 9516 DMA controller chip b programmed to 
do an 8K byte transfer, as in normal dbk operations. Polling the FIFO_FULL bit in the SCSI STATUS 
register will verify that the FIFO b filled. 

To empty the FIFO, the 9516 DMA controller chip b programmed to do an 8K byte transfer from disk 
to memory, but without enabling the 5380 SBC chip and without resetting the FIFO. This will cause all 
8K bytes to read back into memory. 
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5.16. VMEbus Interface 

The VMEbus interface is dual-ported. The VMEbus Master Interface provides access from the CPU to 
the VKffibus, whereas the VMEbus Slave Interface provides access from the VMEbus to the CPU for 
DVMA transfers. (See the chapter on DVMA Devices, below.) ' 

The chart below lists VMEbus options supported by Sun-3 systems. 

• Address Bus Option: A32 MASTER; A32 SLAVE 

• Data Bus Option: D32 MASTER, D32 SLAVE 

• Timeout Period: 100 microseconds minimum excluding bus acqubition 

• Arbiter Option: ONE (single level), can be disabled 

• Requestor Option: ROR (release on request) 

• Interrupt Handler Options: IH(l-7) 

Support for VMEbus read-modify-write cycles requires clarification. Read-modify-write cycles for the 
VMEbus Slave interface are executed as atomic cycles with respect to other VMEbus requests. Atomicity 
between VMEbus Slave accesses to main memory and CPU accesses to main memory, however, b not 
guaranteed. 

Read-modify-write cycles from the CPU to the VMEbus Master interface are guaranteed to be atomic 
with respect to other VMEbus requests. They may, however, not appear on the bus in the read-modify- 
write format defined in the VMEbus specification. 

Normally a Sun-3 CPU board acts as VMEbus arbiter. Jumpers, however, are provided to disable the 
arbiter and permit operation as a non-arbiting VMEbus board. 

Neither the slave nor the master interface supports sequential access modes. Finally, the Sun-3 CPU 
board does not support an interrupter function to the VMEbus. 
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5.17. VMEbus Master Interface 

The VMEbus Master Interface uses two page map Type codes: one for 16-bit data, and one for 32-bit 
data. For each Type code, three VMEbus address spaces are supported: 4 Gbytcs minus the top 16 
MBytes for 32-bit addressing, the top 16 MBytes minus the top 64 KBytes for 24-bit addressing, and the 
top 64 KBytes for 16-bit addressing. 

Sun-3 implementations of the VMEbus Master interface place no alignment restrictions on CPU data: all 
MC68020 alignments will be supported for VMEbus cycles. Data transfers from the CPU into D8 VMEbus 
ports must be byte transfers only; attempts to perform word or longword CPU bus cycles into D8 ports 
will yield erroneous results. 

The timeout period for transfers is implementation dependent but a minimum of 100 microseconds. 
I&ltlklizktion: S«* tb« chuptar oa CPU Rtitt 
Inttrroptt: L«v«l 1 throofh 7, V»ctor«d 

Ezciptio&s: TiavoQt ptriod Bl&lBtui 100 Bicrotacond* 

B*f«r*iic«: Notorolk VKEbni Spvciflcktion 

TTPE DEVICE ADDR DEVICE PHYS. ETACE 



Bota: Tjp« 2 •pn.ca !• VXE2)ui Ifi bit AxX,% >p&c« 

82 bit dtcod* of KVU &ddrati Idtntlflai VXEbnt addrtss >pac« 



2 


0x00000000 


VXEbos AS2 tpac* 


A<31. 


.0> 


2 


OxFFOOOOOO 


YVZbTif A24 sp»c0 


A<23. 


.0> 


2 


OiFFFFOOOO 


VKEbat A16 ipa-c* 


A<16. 


.0> 



Bote Tjp* S tpacc !■ VUEbnt 32 bit d&t& rpict 

S2 bit dacod* of KXU MidratB idtntitiaa WEbu* tddraat tp&ca 

3 OxOOOOOOOO VKEbaa A32 Bpa.ca A<S1..0> 

3 OiryOOOOOO VXEbna A24 ap^ca A<23..0> 

3 OxFFFFOOOO VKEbut A16 ipkca A<15..0> 
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6. DVMA Devices 



There arc four DVM\ devices defined for Suq-3: the AMD Ethernet interface, the Intel Ethernet 
interface, the SCSI interface, and the VME Slave interface. In addition, Sun-3 implementations with 
caches may implement the Cache Flush operation in Control Space as a DVMA request. 

All DVMA devices may access main memory data (Type space) only. Access to addressable but non- 
existing physical memory or to devices other than memory will not complete. How these and other error 
conditions are reported depends on the DVMA device and is described in the Device Space chapter (or the 
Cache chapter, for the Cache Flush operation). 

DVMA requests are assigned the following priority: first, Ethernet; second, the Cache Flush; third, the 
SCSI; and fourth, the VMEbus Slave. All DVMA requests have higher priority than the CPU. 

All DVMA devices must map addresses from a DVMA device address space into a Sun-3 virtual address 
space. This space is identified by a 3 bit Context ED, a 28 bit virtual address, and protection access codes. 
System DVMA accesses are supported from Ethernet and SCSI, plus both System and User DVMA 
accesses from the VMEbus. No protection checking is done during the Cache Flush operation. 

The following sections discuss how DVMA address spaces map into the CPU virtual address space for 
each device. The Device Space chapter includes information on addressing controls for the AMD and Intel 
Ethernet devices and the SCSI interface. The section on Control Space operations in the Sun-3 Cache 
chapter discusses the Cache Flush operation. 

6.1. Ethernet and SCSI DVMA 

The two Ethernet devices (AMD and Intel) and the SCSI interface map address spaces the same. Each 
device's 16MB address space is mapped into the highest 16 MB of the CPU virtual address space for the 
current context, as identified by the Context ID register. 

All three devices support only System DVMA and are assigned Supervisor Data access for protection 
checking. The handling of protection errors, as well as page faults and memory data errors, depends on 
the device; see the Device Space chapter. All memory data errors are reported to the CPU as interrupts, if 
enabled. 

Ethernet and SCSI DVMA are always enabled and are not affected by the EN.SDVMA bit in the System 
Enable register or the User DVNL\ Enable register. 

The Intel Ethernet section should also be consulted about the ordering of control block data in memory. 

6.2. The VMEbus Slave Interface 

The VMEbus Slave interface supports both System and User DVMA into the CPU virtual address space. 
The following features are included in both modes of transfers. 

• Byte, V/ord, and Longword transfers are supported. 

• Both System DV.MA accesses and User accesses are defined entirely by the VMEbus 24 or 32 
bit VMEbus address and the address modifiers identifying the address mode, AM<5..4>. The 
V.\rEbus Address Modifier bits AM<2..0> defining the access protection of the VMEbus 
request are ignored. The 16 bit address space is also ignored. 

o Access to non-existing memory or other (noD-Type 0) devices results in a VMEbus Bus Error 
return. 
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• A VMEbus Bus Error ia also signalled if the DVMA cycle encounters a page fault, protection 
error, or (on read cycles only) a memory error. Memory errors, which include parity errors or 
uncorrectable double bit errors, are abo reported to the CPU as interrupts, if enabled. 
Protection checking is dbcusscd below. 

• Implementations of DVMA can offer bigh-bandwidlh burst modes of transfer that allow fast 
DVMA devices to increase throughput by eliminating repeated bus arbitration. 
Implementations must specify whether this feature is supported and what the device 
requirements must be to activate this transfer mode. 



6.2.1. System DVMA 

System DVMA responds to the lowest megabyte of the VMEbus address range in both the 24-bit and 
32-bit VMEbus address spaces. This 1MB space b mapped into the highest megabyte in the virtual 
address space of the current context, as indicated by the Context ED regbter. System DVMA b enabled 
via the EN.SDVMA bit in the System Enable regbter. System DVMA cycles use Supervisor access for 
protection checking; a VMEbus Bus Error is signalled if the page being accessed is not vali4 or if the 
access has a protection violation. Thb error b not visible to the CPU. 



VKE-Addrtfi A24. A32 



VirtQ&I Addrtii 



[OrOOOOOOOO. .OxOOOFFFFFl 



tOzFFFOOOOO. .OxFTFFFFFFl 



0.2.2. User DVMA 

User DVMA responds to the most significant 2 GBytes of the VMEbus 32-bit address space (i.e., 
A<31> = 1). The 16-bit and 24-bit address spaces are ignored. The VMEbus User DVNtA address space 
contains two fields. VMEbus A<30..28> map into a 3 bit context ED, and VMEbus A<27..1> with DSO 
and DSl map directly into the 28 bit virtual address space for this context. User DVMA is enabled via 
the User DVMA. enable regbter, which has one bit per context. If a context b not enabled for user DVMA, 
then the CPU does not respond to the corresponding addresses on the VME cycle at all; this allows 
sharing of the upper 2 gigabytes of the VME address space with other VME devices. 

User DVMA cycles have User access for protection checking; a VMEbus Bus Error is signalled if the 
page being accessed is not valid or the access has a protection violation. This bus error is not vbible to 
the CPU. VMEbus masters that expect bus error support from the CPU must then post an interrupt to 
the CPU and must make the appropriate information about the bus error available to the CPU. 



V1E-Addr»«« 



Vlrtnil Addrttt 



tOxeOOOOOOO. .OiBFFFFTTT] 
[0x00000000 . . OxOnTFFTT] 
[OrAOOOOOOO. .OiAFFFFFTF) 
lOxBOOOOOOO, .OxBFFFTFFF] 
[OxCOOOOOOO. .OxCFFTTFTF] 
[OxDOOOOOOO. .OxDrFTTFTF] 
[OxEOOOOOOO. .OxErFFFFTF] 
[Oxf 0000000. .Cx5T777TTF] 



CX=0 [0x00000000.. OxOFFFFTFFl 

G(=l [0x00000000.. OxOFFFFFFF] 

CX=2 [0x00000000.. OxOFFTFFFT J 

CX=5 [0xO00000O0..0xOnTFFT7] 

CX=A [0x000C0000..0xOFFFFF77] 

CX=B [0x00000000.. OxOFTTFTFF) 

CX=0 [OxCOOOOOOO.. OxOFFFFFFF] 

CX=7 [OxOOOOOOOCOxCFFFFFFF] 
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7. CPU Reset 

There arc five possible reset sources for Sun-3 configurations: Power-On reset, VMEhus SYSRESET-, 
Watchdog reset, a User Reset switch, and CPU reset. Two of these, the VKiEbus SYSRESET- and the 
User Reset switch, are optional by configuration. 

The following chart indicates the devices or system bus signab that are reset by each source. Following 
the chart, each reset source b described. 
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ECC M««ory Eaablt r.j Y 
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ECC Chip Dlxg. T»z 
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Y B Alwiy* r»s«t tb« indlc&ttd d«Tic« durlag th« icdic^tad 

r«B»t condition. 
B B Bn^ juapar option: R«s«t lndlck.t»d CPU doTlcii If WEbno 

SYSRESET- If drlTta »ctlTt (=0) frca iob* VKEbo* bo*rd. 
P o CPU-to-bn« Jti«p«r option: Drlrt VKEbui SYSRESET- actlT* 

(cO) daring lndlc».t«d r««»t condition for CPU bo&rd. 

Power-On Reset. Po-wci-On Reset (POR) is active for 100 milliseconds minimum after the power supply 
voltage reaches 4.5V. POR resets the CPU and clears the System Enable register forcing boot state, and 
it resets the diagnostic register, lighting all the LEDs. Other devices reset during Power-On reset are 
indicated above. 

VMEbus SYSRESEH'-. The VMEbus SYSRESET- must be activated by a jumper in configurations with 
a system bus, normally only in the event that the CPU board is not the VMEbus arbiter. If so jumpered, 
the CPU board does not itself drive SYSRESET- or SYSFAIL- if the bus SYSRESET- b active. 

Watchdog React. The Sun-3 architecture provides a watchdog circuit which generates a signal equivalent 
to power-on reset (POR) whenever the CPU halts with a double bus fault. A Watchdog Reset results in 
the same devices being reset as the Power-On reset. 

User React Switch. An optional User Reset Switch resets the same devices aa the Power-On Reset. 

CPU Read. CPU Reset results from the CPU executing a Reset instruction. 
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8. CPU Interrupts 

8.1. Interrupt Sources 

There are two sources of interrupts for Sun-3 systems: VMEbus interrupts and interrupts from devices 
defined in the Sun-3 architecture. 

The VMEbus interrupt handler for Sun-3 systems supports all levels (1:7) of VMEbus interrupts. 
VMEbus interrupts have lower priority than onboard device interrupts at the same level. 

A list of the interrupt assignments for devices defined in the Sun-3 architecture is in the table below: 
L«T*1 D«Tic«Ca) 



7 Masory Error or Clock 

e SCCt 

5 Clock 

4 Vldvo (Saa-S Fma* Bnfftr or Color Va.p) 

3 Ethtrnat or Sjstaa £&a.bl« R«gi«t«r 3 

2 SCSI or Sjttta En&blt R*siit*r 2 

1 Sjitaa En&bl* R«gltt«r 1 



8.2. Interrupt Acknowledge Cycles 

Interrupt acknowledge cycles are CPU Space cycles identified by A<17..16> = '11'. The interrupt 
vector number resulting from the execution of an interrupt acknowledge cycle may be a vector fetched 
from the interrupting device, an autovector corresponding to the level of the interrupt acknowledge cycle, 
or a spurious interrupt vector. 

All Type 1 devices defined in the Sun-3 architecture use autovectored interrupts, except for the SCC 
UART's. Either vectored or autovectored interrupts may be implemented for UART's, with vectored 
being the preferred implementation. Devices on the VMEbus use vectored interrupts. 

A spurious interrupt vector results whenever an interrupt acknowledge cycle terminates by the assertion 
of the bus error signal. Certain implementations of Sun-3 report spurious interrupts. In particular, the 
failure of a device to return a vectored interrupt may be reported as a spurious interrupt. The contents of 
the Bus Error rcgbter are not affected by the reporting of spurious interrupts. 
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9. The Sun-3 Cache Architecture 

9.1. The Sun-3 Cache: Introduction and Overview 

9.1.1. The Sun-3 Cache: Introduction 

The Sun-3 cache architecture describes a set of caches with a common structure. Id particular, all Sun-3 
caches are direct mapped caches (i.e., one way set associative) with a fixed block size. They vary only in 
the number of cache blocks. 

The number of cache blocks, together with other options indicated in the architecture, are Sun-3 cache 
implementation parameters. These parameters must be specified as part of the product specification. 

9.1.2. The Sun-3 Cache: Overview 

The Sun-3 cache is organized as a direct mapped virtual addressed cache containing 16 byte blocks (or 
lines). Its size is variable, from IK blocks (16K bytes) up to 8K blocks (128K bytes) for the largest 
allowable Sun-3 cache. 

Sun-3 caches support 8 virtual contexts with 28 bit virtual address spaces. 

For each 16 byte cache block there is a corresponding cache tag field. The tag field contains address 
information to uniquely identify the block data plus protection and control information. 

In the smallest Sun-3 cache, a cache block and its corresponding tag field are addressed by A<13..4>; 
in the largest Sun-3 cache, < the block and tags are addressed by A<16..4>. To uniquely identify the 
virtual address for a cache block, its tags contain the 3 bit Context ID (CDD) field plus a varying number 
of virtual address bits, depending on the cache size. 

The tag field for the smallest Sun-3 cache contains address bits A<27..14>. Together with the cache 
address, these tags uniquely identify the block address, A<27..4>. Similary, the largest cache tags include 
A<27..17>. (See below for a description of all tag bits.) 

The Sun-3 cache contains only data from main memory. That is, each cache block's virtual address must 
translate into a physical address from a Type page in Device Space. Data from any Type page which 
is not marked "Don't Cache' in the MNflJ may be cached; this includes, in particular, data accessible by 
User or System DVMA. 

9.2. The Sun-3 Cache: System Programming Requirements 

Sun-3 caches are virtual address caches; implicit with the use of a virtual address cache is a set of 
system programming restrictions which KfUST be adhered to in order to guarantee system data 
consistency. In addition, other restrictions on the mapping of Supervisor pages are required for optimal 
cache performance. 

9.2.1. Data Consistency: Overview 

Virtual addressing allows aliaiing: the possibility of multiple virtual addresses mapping to the same 
physical address. If a Sun-3 cache were used without system page mapping restrictions, any two arbitrary 
virtual addresses could occupy any two arbitrary cache locations and still map to the same physical 
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address. When cache blocks are modified, Suu-3 cache hardware provides NO data consistency checking 
between different cache blocks. Data can become inconsistent when changes at one cache location arc not 
seen at another cache location. Ultimately, the data at the common physical address in main memory are 
goins to include only part of the Write modifications from the several cache locations. 

The Sun-3 cache architecture solves this data consistency problem by providing two distinct 
mechanisms. Doth mechanisms require the interaction of software with special cache hardware to ensure 
consistent data. Briefly, the first mechanism requires that all alias addresses which map to the same data 
must match in their low order 17 bits (modulo 128KB) IF these data are to be cached. The second 
mechanism restricts data from being cached through the use of a "Don't Cache* bit which is definedfor 
each page in the MNiU Page Map. 

Both of these mechanisms are explained in more detail below. 

0.2.2. Data Consistency through Modulo 128K Addressing 

The first, and prefered, method of guaranteeing data consistency is through restricting the use of alias 
addressing for cache data. To guarantee that all alias virtual addresses map to a common cachp location, 
it is REQUIRED that any two alias virtual addresses must match in their low order 17 bits (i.e., modulo 
128K). This applies to alias addresses within the same context as well as aliases between contexts. 

Note that to guarantee data consistency, ANY write to a page requires that ALL references to that page 
(read or write) adhere to this restriction. No requirement is placed on alias addressing to Read Only pages. 

Also note that other means are available to guarantee limited data consistency, for example, in alias 
addressing between User contexts. If the operating system flushes the cache through 'Flush Cache Set 
(Context Match)' commands in Control Space at the time of User context switches, then data consistency 
between User contexts is assured. The cache flush, however, is relatively slow and does nothing for alias 
addressing within the context. Further, cache blocks with Supervisor protection arc unaffected by this 
flush command. 

The hardware controls to guarantee data consistency within a single cache block are described in the 
section "Cache Misses and Data Consistency' below. 

9.2.3. Data Consistency through Don't Cache Pages 

The second mechanism to ensure data consistency is through the use of a "Don't Cache Page' bit in the 
M-MU Page Map. If this control bit is set for a page, then all data accesses to this page are made directly 
to and from main memory. In bypassing the cache, the virtual cache data consistency problem is avoided. 

Since alias addressing is possible, if a page b marked "Don't Cache" in one MMU Page Map entry, then 
it must be marked "Don't Cache' in all alias Page Map entries. Data consistency is not guaranteed 
otherwise. 

Generally, direct memory data accesses are much slower than cache accesses. Frequent references to 
"Don't Cache" pages will consequently harm system performance. 

9.2.4. Mapping of Supervisor Pages 

There are two additional requiremcLts for the mapping of Supervisor pages on systems implementing a 
Sun-3 cache. These requirements are not related to cache data consistency, but rather arc fundamental to 
the definition of a cache "blf; see the section •Dcfinilion of a Cache Hit" below. 

First, the Sun-3 c.-vchc architecture requires that all Supervisor pages must have identical address 
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mappings across all contexts. 

Second, for protection consistency, the Sun-3 cache architecture requires that if a page is marked as 
having Supervisor access within one context, then that page must be marked as having Supervisor access 
for all contexts. 

These requirements ensure that, with the cache hit and protection definitions stated below, no 
differences in data protection should be discernable whether a Sun-3 cache is enabled or disabled. 

9.3. The Sun-3 Cache: Its Structure and Operation 

9.3.1. Cache Tags 

Sun-3 cache tags are listed below. The use of these tags in cache control b explained in the next section. 

o Valid (1 bit): Indicates that the tags and data at the addressed cache block are both valid. 
Neither tags nor data have meaning if the Valid bit is reset. 

• Modified (1 bit): Indicates that the cache block has been modified by one (or more) Write 
cycles. 

• Virtual Address field (from 11 to 14 bits, depending on cache size): Virtual address bits which, 
together with the cache address, uniquely identify a cache block in a 28 bit virtual address 
space. For a 16K byte Sun-3 cache, the Virtual Address field is A<27..14>; for a 128K byte 
Sun-3 cache, the VA field is A<27..17>. 

o Protection (2 bits): Write Allowed and Supervisor Access protection bits, identical to those in 
the MMU. The use of the Protection bits is explained below under Definition of Cache 
Protection. 

• Context ED (CID) field (3 bits): Identifies the Context for the cache block. 

• Reserved (3 bits): May be read or written, but have no effect. 

• Unused VA bits (Variable; depends on cache size): Unused VA bits are undefined. 

• Unused (8 bits): Unused bits (D<7..0>) are undefined. 

SiriTix Cack* T&f forBa.t (for R«&d/Vrit« Tig Control Sp&c* op»r».tioni): 

D31 D50 D20 D28 D27 026 D25 D24 D23 D22 D21 D20 DIO D18 D17 018 
|Vall«od|R»»»rTdl< Vlrtnil Addren 

D15 D14 D13 012 DU DIO 000 008 007 DOS 005 004 DOS 002 001 000 

— VA— >|ffrt|SnplRt-|< CIO >1< Vamtd >| 

con't. lProt«ctl«»rT»d 
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0.3.2. Accessing the Cache 

Cache operations include read cycles, write cycles, and Control Space operations. To access the cache for 
any of these operations, generally the following information is required: a Device Space/Control Space 
indicator (Function Code bits; implementation dependent); a 3 bit context I.D. (from the CID register or 
VME address bits A<30..28>); the 28 bit virtual address (A<27..0>); the Supervisor/User access bit; a 
Read/Write bit; and the data transfer size (Size bits; encoding is implementation dependent). On write 
cycles, up to one longword of data is also required; the data alignment is implementation dependent. 

All of this information is required for cache read and write cycles. On Control Space operations, some 
may not be required; see the Control Space section, below. Timing requirements at the cache interface for 
this information are implementation dependent. 

0.3.3. Definition of a Cache Hit 

In this section, the cache •bit" is defined for read and write cycles and for the Block Copy (Read) and 
Block Copy (Write) Control Space operations. The "hit" criteria for other Control Space operations are 
explained in the Control Space section, below. ' 

There are two requirements for a cache hit. First, the access address A<27..4> must match the cache 
virtual address tags plus the cache block address. 

Second, either the access context ED must match the cache Context ID tags, or the cache Supervisor 
protection tag must be set. If the cache Supervisor Access tag is set, then the cache block may be accessed 
regardless of the access context ID. 

This 'hit' definition does not necessarily imply a valid cache access, since it takes no account of 
protection checking (below). 

0.3.4. Definition of Cache Protection 

Cache protection checking is defined for read and write cycles and for the Block Copy (Read) and Block 
Copy (Write) Control Space operations. Protection checking in inhibited on all other cache specific 
Control Space operations and during "Write Back" cycles (see Cache Access and Block Replacement, 
below). 

There are three requirements. First, no cache protection violation can result unless there is a cache hit. 
Second, if the access has User protection, a protection violation results on a hit if either the cache block 
has Supervisor protection, or if the access attempts to write into a cache block whose Write Allowed tag is 
reset. Third, if the access has Supervisor protection, a protection violation results on a hit only if the 
access attempts to write into a cache block whose Write Allowed tag is reset. 

A protection violation terminates the bus cycle with a bus error, while setting the Protection Error bit in 
the Bus Error register (on CPU bus cycles). 

0.3.5. Enabling the Cache 

The "Enable External Cache" bit, D<4> of the System Enable register, determines whether the cache 
is enabled for read and write cycles. In Boot state, the cache is disabled. If disabled, all cache accesses 
"miss" the cache, no cache blocks arc written back to memory, and memory data are directly read from 
or written to main memory. Block Copy (Read) and Block Copy (Write) Control Space operations 
operate from main memory, ignoring the cache. All other Control Space operations for the cache, 
however, remain unaffected by the Enable bit. 
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0.3.6. Cache Initialization 

The st:\tc of a Sun-3 cache following a Power-On reset, User Switch reset, or Watchdog reset may be 
indeterminate. The reset forces the Enable External Cache bit (above) to be inactive. To initialize the 
cache, the Valid tags for all cache blocks must be reset by issueing 'Write Cache Tags' commands in 
Control Space before the Enable External Cache bit is set active (see Control Space, below). 

9.3.7. Read and Write Cycles: Cache Hit Operation 

For the Sun-3 cache, read and write cycles begin by determining whether the cache access 'hits' or 
"misses" the cache. If the access "bits' the cache, then a protection check is made. If a protection 
violation is found, a protection error terminates the bus cycle; no valid data are read (read cycle) or 
written (write cycle), and no block tags are updated. 

If no protection violation is found, the cache cycle is valid. On a valid read cycle, up to a longword of 
cache data b read from the cache. Data alignment is implementation dependent. On a valid write cycle, if 
the Modified block tag is active, then up to a longword of access data is written into the block. The sizes 
of data updates and alignment requirements are implementation dependent. No block tags are updated on 
either of these cycles. 

If the Modified tag is inactive on a valid write cycle, then both the Modified block tag bit and the 
Modified bit in the MMU Page Map must be updated. The cache data may be rewritten from memory 
data during the tag and MMU update, depending on the implementation. Cache data will be updated by 
writing up to a longword of access data into the block. Again, the sizes of data updates and alignment 
requirements are implementation dependent. 

9.3.8. Read and Write Cycles: Cache Miss Operation 

A cache "miss' on. read and write cycles in Device Space may be caused by either an access to a 
cacheable Type page whose data are missing from the cache, or by an access to a 'Don't Cache" page 
or a non-Type page. Reading the M.MU Page Map determines whether the access data should be in the 
cache. 

If the MMU translates the access address to a valid Type page whose 'Don't Cache' bit b inactive, 
then the cache will be updated at the block corresponding to the access address on both read and write 
cycles. The cache tags will be updated to i^ow the access context and virtual address, the Valid bit will be 
set active, and the Modified bit will be set .)n a write cycle. 

9.3.9. Cache Misses and Data Consistency 

The source of a valid block of data to update the cache following a cache 'miss' may be either Type 
memory or the old cache block data. The selection depends on the contents of the old cache block to be 
replaced. If the cache block contains an invalid entry, then the source of the data update is memory. If 
the cache block b valid, then data consistency issues determine the source. 

In the section 'Data Consistency through Modulo 128K Addressing' above, it was stated that cache 
data consistency would be guaranteed if all alias addresses were to map to a common cache location 
modulo 128K. Wiih modulo 12SK addressing, it is possible that the access virtual address and cache tag 
virtual address both translate to the same physical block. The Sun-3 cache architecture requires a 
physical address comparator to determine whether the translated block addresses arc identical. The 
number of address bits compared in the physical addres.s comparator is implementation dependent. 
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If the physical addresses compare, then the Rource of valid data to update the cache is the old cache 
block data. If the old cache block has doI been modified, then the cache data and memory data arc 
identical. Either can serve as the data source, depending on the implementation. If the old cache block has 
been modified, then the old cache data must be the source for the cache update. 

Once the source of valid block data has been determined, the access cycle can complete. On read cycles, 
up to a longword of data may be read directly from the source or from the cache following the cache 
update, depending on the implementation. On write cycles, up to a longword of access data may be 
written into the cache. The size of data updates and cache data alignment are implementation dependent. 

9.3.10. Write Back Cycles 

The Sun-3 cache is a write-back cax:he: modified data are held in the cache until a cache block b either 
replaced (on a cache miss) or flushed (see the Control Space section, below). Memory cycles which write 
modified cache blocks back into memory are called Write Back cycles. 

Following a cache "miss" on a read or write cycle, the cache block addressed on the access will be 
updated, provided the access address translates to a cacheable page. The sources for the update may be 
cither the old cache block data or main memory (see above). If the source is the old cache block, cache 
data need not be rewritten to memory. If the source is the main memory, then an old cache block which is 
valid and modified must be written back to memory. This cache data may be temporarily buffered; the 
architecture does not require that the Write Back cycle to memory complete prior to updating the cache 
with new data. 

Similarly, during a Flush Cache Set operation in Control Space, valid and modified cache blocks must be 
written back to memory if they satisfy the "flush match' criteria. 

During a Write Back cycle, the virtual address for the block being rewritten must be translated in the 
MMU. Any translation error is signalled as a "Write Back" error interrupt to the CPU. No protection 
checking is performed. 

9.3.11. Cache Error Conditions 

There are two types of errors unique to systems with Sun-3 caches. These are Asynchronous Time Out 
errors and Write Back errors. 

In Sun-3 systems with caches, a time out error may be reported differently, depending on when the 
condition b detected. If the condition is detected while either a CPU or DVNIA bus cycle b in process, 
then the time out is reported as a bus error to the CPU or DVNIA master. On CPU bus cycles, the 
TIMEOUT bit (D<5>) in the Bus Error register records the cause of the error. (See also the Bus Error 
regbter description.) 

If the time out error is detected during a Write Back cycle (above), then it is reported, if enabled, as an 
interrupt to the processor. The TIMEOUT bit (D<3>) in the Memory Error Control register records this 
error. 

■- A Write Back error results whenever a translation exception is detected for the address of a valid and 
modified cache block which must be written back to memory during a Write Back cycle (above). This 
error, if enabled, is also reported to the processor as an interrupt and is recorded as the WBACKERR bit 
(D<2>) in the Memory Error regbter. Note that no protection check is performed during the Write 
Back address translation. 
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9.4. The Sun-3 Cache and the MMU 



9.4.1. The MMU Accessed Bit 

In Sun-3 systems with no cache, an MMU Accessed bit is updated on every bus cycle to memory. In 
Sun-3 systems with a cache, no MKfU update is made if the memory read or write access "bits" the cache. 
If the operating system resets an MMU Accessed bit, this means that the bit will not be set again in cache 
systems until there is a cache miss for data contained in that page. Note that the Control Space 
commands Block Copy (Read) and Block Copy (Write) may also update the MMU Accessed bit. 

As a consequence, MMU Accessed bits may be somewhat inaccurate in reflecting page uscage within 
Sun-3 systems with caches. 

9.4.2. Modified Bits for the Cache and MMU 

The cache and MMU Modified bits are coordinated as follows. If a Write access misses the cache, then 
the MMU Access and Modified bits plus the cache Valid and Modified bits are all set active when data are 
returned from main memory. For subsequent Writes to the same cache block, no tag updates are 
required. 

If a Read access misses the cache, then the MMU Access bit and the cache Valid bits are set active when 
data are returned from main memory. If a subsequent Write access to this same block occurs, then both 
the cache Modified and MMU Modified bits must be set active. Again, subsequent Writes do not affect 
the cache tags. 

9.4.3. Write Back Cycles, Control Space Operations, and the MMU 

Write Back cycles and Control Space operations (see below) require special mention regarding their use 
of the MMU. MMU translations arc required during Write Back cycles, flushes, and Block Copy 
operations. During Write Back cycles and flushes, NO protection checking is performed; checking is done 
for Block Copy operations. 

The MMU is never updated on Write Back cycles or flushes. On Block Copy (Read) operations, the 
MMU Accessed bit of the block read is updrted if the block is not in the cache. On Block Copy (Write) 
operations, the Accessed and Modified bits z.ce both updated. 

9.5. Control Space Operations for the Sun-3 Cache 
9.5.1. Control Space Operations: Overview 

There are four Control Space operations for the Sun-3 cache. These are Read/Write Cache Tags; 
Read/Write Cache Data; Flush; and Block Copy. 

The sizes of data transfers supported for cache Control Space operations are implementation dependent. 

Detailed descriptions of the cache control operations are given below. The following notation is used: a 
data bit value of "d" indicates 'Don't CareV 



Sun Microsystems Inc CONFIDENTIAL IG May 1085 



Sun-3 Architecture Rev 2.0 Prelim The Sun-3 Cache Architecture 49 

9.5.2. Read/Write Cache Tags 



RECISTER/MAP A<31..28> D<1..0> SIZE TTPE ADDRESS FIELD 
CACHE TAGS OzQ LOIC R/f A<16..4>« 
• Addrtai tlald (or 1280 crncb*; A<ia..4> for 160 each* 



A R«k4 or Vrit* coaaa.Bd la Control Spue*. 

At tb* kddr»is«d c»cb« block. R«i4 or frit* tb« c»cb« t».{t «.• 

data, la a 32 bit foraat. 
Data fl*lda: 

DSl D50 D20 D28 D27 D26 D26 D24 D23 D22 D21 D20 DIO D18 D17 DIO 
I 1 1 1 1 

|Val|Mod|R»f«rTdI< Virtual Addrtsi 

D16 DU DlS D12 DU DlO D09 D08 DOT DOS DOS D04 DOS D02 DOl DOO 
I 1 1 1 1 

—VA— >|¥rt|Sup|R«-l<— CID >|< Unoitd >| 

co&'t. tProttctlstrrtd 

Data foraat: 

32 bit Closlcal) data, D<S1..0>. 
Unoftd bits D<7..0> ar* oadaflatd. 

Slzti of data traatfari tnpporttd ara laplaaaatatioa dapandant. 

Nota: Irltlnf all Valid bits vltb O'a Inltlallzaa tba cacba. 
Baa Error Condltloaa: Rona. 
Intarrtjptc Gaaaratad: Noaa. 



9.5.3. Read/Write Cache Data 



RECISTER/IAP A<31..2Q> D<1..0> SIZE TYPE ADDP-ESS FIELD 

CACHE DATA 0x0 LOIC R/¥ A<10..2>» 

• Addraaa flald for 128KB cacba; A<13..2> for ICKB cacba 

Addraaa aota: A<S..2> addraaa a Lonsrord vltbin a cacba block. 



A Raad or Vrlta co&aaad la Coatrol Spaca. 

Raad or trlta tba cacba data at tba addraasad cacba block. 

Cacba tags ara aot cbackad for tblt oparatlon. 
Data foraat: ' 

32 bit data, D<31..0>. 

Sizaa of data tranafar* anpportad ara iapltatatatlon dapandant. 
Bna Elrror Conditiona: Ron*. 
Intarropta Gaaaratad: Roaa. 
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9.5.4. Flush Cache Operations: Overview 

Three Flush Cache operations are defined, depending on the match criteria: the context match flush, the 
page match flush, and the segment match flush. All operations operate over a set of cache blocks. A R«t b 
defined as one or more cache blocks, the number of blocks being a power of two and implementation 
dependent. The starting address for a set is specified in the command, with the assumption that lower 
order address bits are O's. By incrementing the set address, a sequence of Flush Cache Set commands will 
flush the entire cache. 

Each cache flush command may change the cache in two ways. First, each flush command causes all 
Valid and Modified blocks from the set which satisfy the flush match criteria to be written back to main 
memory. Second, each flush command causes all Valid blocks within the set which satbfy the match 
criteria to be invalidated. 

The match criteria for flush commands are defined below. 



9.5.5. Flush Cache Set [Context Match] 



REClSTER/»tAP A<ai. .28> D<1. .0> SIZE TYPE ADDRESS F I E3J) 



FLUSH CACHE OxA 'Ol* K/A TRITE CX<2..0>, A<18..'t>»» 
SET (COHTEXT) 

• • A<ia..4> corr«>poBda to 128KB c&ch« (bu) vith 1 block S«t (•!&) 

Upp«r boand of A<16..4> Taritt vlth ci,cb« tizi; 

Lovar boond of A<16..4> T&riti «ith Set lizi for flnih 

Iln. addrsit fitld s CX<2..0> (with S«t ciza fi each* siza) 



A Vrlt* coamaiid la Control Spac*. 

OptratloQ vosjiary: Finish froi tb« each* ivll each* blocka witbin 

a rp«clfi*d contart vbicb art troa U«( " protected pagei. 
Flneb aatcb criteria: Tbe Scperrlcor pre ection tag antt be 
reset (User space), aad tbe CoBtert II tags oust s tbe 
Context ID register (3 bits). 
Data format: 

(D<1..0> B '01') identifies tbis fins' conaand as a Context 
Hatcb flneb. 
IGtfU notes: Eo lOfU protection cbeck is d m, and no cpdate is 

perforaed on KVU Accessed or Uodifiec: bits. 
Error interrupt condition: 

Vrite Back error if tbe address translation for a Valid and 
Modified cacbe block is lnT».lid. 
Votes: 

A Context Flnsb is need to enstire cacbe addreesin^ coneietencj 
vbeneTsr a nes actlre context replaces an old context in tbe 
KTtU. Tbe Context Flnvb anst be perforaed before tbe old 
context references are reaoved froa tbe VUU. since tbe tYPJ 
is required to translate tbe cacbe blocks' Tlrtnal addresses. 
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9.5.6. Flush Cache Set [Page Match] 



RECISTER/KAP A<31..2e> D<1..0> SIZE TYPE ADDRESS FIELD 

FLUSH CACHE OxA 'lO* It/A WITt CX<2..0>, A<27..1S>, 
SET (PACE) A<12..4>«* 

•• A<12..4> eorr*tpondt to 1 block Stt (ain) 

Lo««r boa&d of A<12..4> vari** vltb Stt lizt tor tlQfh 

Mln. addrts* flsld ■ CX<2..0>, A<27..1S> («ith S*t (iza » eXB) 



A Writ* coaa&nd is Costrol Spa.c«. 

Opvriktioa tUBsarj: Fluah froa tb« cacba all c&cb* blocks vithlD 

a •p*citi»d pftg*. ragardlvaa of tb* p&f» prottction. 
Fln«h aatcb crltaria: Tvo crltaria auat ba aatiafiad. 

Firtt, tba c&.cba block*! Tirtua.1 pa.;* addrasa A<27..13> aaat 
a&tcb tba hccaaa pa.ga ».ddracB A<27..1S>. Ona (or aora) bita froa tba 
cacha block'a pif* addrata A<27..13> fora part of tba cacba addraaa; 
tba otbara ara tag bita. Tba booadarj batwaan tha ta( bita and tba 
cacba addraaa fiald ia iaplaaaQtation dapandant. For axaapla. ia a 
leXB cacba. A<1S> it part of tba cacba addraaa. and A<27..14> ara taga. 
Tba tacond critarioa ia tbat aitbar tba cacba block'a Soparviaor 
protaction tag ba actira or tbat tba cacba block'a Contart ID 
fiald aatcbaa tba Contart ID ra^ittar. 
Data foraat: 

(D<1..0> s 'lO') idantifiaa tbia flnab coaaand aa a Paga 
Katcb flnab. 
mtU notaa: lo WU protaction cback ia dona, and no npdata ia 

parforaad on KVU Accassad or Kodifiad bita. 
Elrror intarrnpt condition: 

frita Back arror if tba addraaa tranalation for a Valid and 
Kodifiad cacba block ia inTalid. 
lotaa: 

Tha Pag* Flaah' ia naad daring paga aanagaaant to pnrga all 
rafarancaa to a rirtnal paga froa tba cacba. It anat ba 
parforaad bafora tba KUU ia npdatad to raaoTa tba paga, 
sinca tba KXU ia raqnirad to trinalata tba cacba blocks' 
Tirtnal addrtaaaa. 
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9.5.7. Flush Cache Set [Segment Match] 



RECISTE^tAP A<31..28> D<1..0> SIZE TYPE ADDRESS FIELD 

FLUSH CACHE OxA '11* M/A WITE CX<2..0>, A<27..17>, 
SET (SECIC3IT) A<18..0»« 

•♦ A<10..4> corrtiponds to 128KB each* (ku) «lth 1 block Sat (aln) 
Upptr bonad of A<10..4> T&riti «lth c&cha six*: 
Lovtr bOQ&d of A<1B..4> Y&rl«t vlth S«t ■iz« for flxiiix 
Min. Midrtaf fi«ld a CX<2..0>. A<27..17> («itb S«t viz* « c&ch<) 



A Vrlt* coBauid in Costrol Spac*. 

Optratlon CQBB&ry: Floih froa tht cacbt a^ll c&cb* blocks vitbln 

a sptcifltd ••(«»Dt. r«sirdl«t« of tb* p&j* prottctlon. 
FlTjsb »&tch crittrla: Two crit«ri& anst b» tatlBfivd. 

Plrat, tb* ■•^•Qt &ddr»at A<27..17> froa tb* ct,cb« block's virtQEl 
&ddr»>a tiigc aoft a&tch th« t.cc«t* aapitnt ^ddraas A<27..17>. 
Tba aacoad critarioa la tb&t aitbar tba c&cba block'a SoparTlaor 
protactlon tt.g ba actlTa or tb&t tba cn^cba block's Coatazt ID 
flald Bfttcbaa tba Contaxt ID raglatar. 
Da.ta toraa.t: 

(D<1..0> s *11') IdaBtifias tbia flusb coaauvd &a & Sonant 
Mitcb flsab. 
UMU Dotaa: Ko KUU protactioa cback la dona, iiad no Tipd&ta la 

parforaad on KVU Accaiiad or Kodlflad bita. 
Error Intarrapt condition: 

Vrlta Ba.ck arror If tba ■.ddraas tn^nalitlon for ^ Valid and 
lodiflad cacba block la inralld. 
lotaa: 

Tba Savant Flaab la aaad daring paga aanacaaaat to pnrga all 
rafaraacaa to a rlrtnal aagnant froa tba cacba. It la 
raqalrad wbonarar aa actlva Paga Vap Entry Groap (PKEC) 
aaat ba raplacad. It anat ba parforaad batora tba KVU la 
apdatad to ramora tba PMEG. alnca tba MVU la raqalrad to 
translata tba cacba blocka* Tlrtaal addraaaaa. 
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9.5.8. Block Copy: Introduction 

Block Copy (Read) and Block Copy (Write) arc commands which, executed in sequence, cause a block of 
data to be moved from one block address to another while maintaining cache data integrity and avoiding 
the displacement of any valid blocks from the cache. The source block for a Block Copy sequence may be 
either a cache block or main memory; the destination is always a block in main memory. 

Block Copy (Read) and (Write) must maintain cache data consistency. For both Block Copy (Read) and 
(Write), the virtual address hit criteria are the same as those used in cache read and write accesses. An 
additional comparison is required for both Block Copy (Read) and (Write) if the command address 
■misses' the cache. In thb case, the translated physical address for the command must be compared with 
the translated cache block address. If they match, the command address and cache block address are 
synonyms, and the command must be handled as a cache *hit". 

In what follows, the term 'hit' indicates cither a virtual address •hit* or physical address match. If a 
Block Copy (Read) command •hits' the cache, the source block for the copy operation is taken from the 
cache; otherwise the source is in main memory. No protection violation can occur, since Block Copy 
(Read) has Supervisor read access. The MMU Accessed bit is updated if the Block Copy (Read) command 
•misses^ the cache. 

The destination of the Block Copy (Write) command is always main memory. If the Block Copy (Write) 
command 'hits^ the cache, then the cache block must be invalidated. A protection violation for the Write 
command will result if the page for the destination block prohibits writes. A protection violation prevents 
both writing the block and updating the MMU. Otherwise, both the MNfU Accessed and Modified bits will 
be updated by a valid Block Copy (Write) command. 

Certain restrictions apply to the instruction sequence which may be executed between a Block -Copy 
(Read) and Block Copy (Write). First, if any changes are made to the source block following the execution 
of a Block Copy (Read) but before a Block Copy (Write), the results of those changes are unpredictable in 
the Block Copy (Write) block. Second, if any other Block Copy (Read) or (Write) commands are executed 
during the instruction sequence, the results cf the original Block Copy commands are unpredictable. 

Implementations of Block Copy command; may vary. Command formats are given below. 
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9.5.9. Block Copy [Read] 



RECISrni/KAP A<ai..28> D<1..0> SIZE TYPE ADDRZSS FIELD 
BLOCK COPY (READ) OxB I/A READ CX<2..0>. A<27..4> 



A R«k4 coBJiksd la Control Sp&c«. 

Oparfttloa: S«« &boTa. 

Dkta fora^t: I/A. 

Error interrupt coaditioa: UX trror (l»pl»Bi&tk.tioa d»p«nd«nt). 



9.5.10. Block Copy [Write] 



REGISTER/MAP A<S1..28> D<1..0> SIZE TYPE ADDRESS FIELD 
BLOCK COPY (TOITE) OxB I/A WRITE CX<2..0>. A<27..4> 



A Writ* coM&ad In Control Sp&c«. 

Op«rm.tlon: S** i.t>oT*. 

Data, tora&t: I/A. 

Error i&ttrrvpt condition: ECC trror (lipltntat^tiou dtptndtnt). 
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10. The Sun-3 ECC Memory Architecture 

10.1. The Sun-3 ECC Memory: Overview 

ECC memory is the standard memory for Sun-3 systems with caches. However, the ECC memory 
architecture, as specified below, is not restricted to cache based systems alone. 

ECC memory requires three control registers on each memory board mapped into the Device Space. One 
of these registers initializes the base address of the memory board; the base address of each board b 
restricted to be a multiple of the size of the board. (For example, the base address of an 8 MB board must 
be located on an 8 MB address boundary.) The second register captures the failing address and syndrome 
on single bit errors, and the third defines the mode and operation of the ECC chips. 

The contents of these registers and how they are accessed are dbcussed in the following sections. 

In addition, the Memory Error Control and Memory Error Address registers on the processor board 
control and record ECC error interrupts to the processor. See the section •Memory Error Registers" 
above for a discussion of these registers. 

10.1.1. ECC Memory Operations 

The following operations are supported by ECC Memory: 

• Bus Memory Cycles: Read and write main memory in response to CPU, DVMA, or cache 
Write Back bus cycles. 

o Register Access Cycles: Read and write memory control registers. All registers are addressable 
through a single Type 1 page in Device Space; see below. 

• Refresh Scrub Cycles: If enabled, a data scrub will be performed during memory refresh. 

10.1.2. Memory Error Conditions 

There are two error conditions which may be detected in ECC memory: Correctable Errors (CE's) and 
Uncorrectable Errors (UE's). These may be detected during cither memory access cycles or refresh scrub 
cycles. 

How these errors are reported to the processor (or DVMA master) is discussed below. 



10.2. Error Reporting for ECC Memory Systems 

The following sections summarize first the controls to enable error reporting and second how the error 
reporting differs according to the type of memory cycle and error. 

10.2.1. Enabling Error Checking and Reporting 

A table listing the names and functions of enable bits for error reporting is given below. 
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5C 



taftVl* Bit/ 
R»ClBt»r/Dd 



Appll«a Oft 
Htftorj Cjclt* 



F«nctloft of 
Eaftbl* Bit 



ECC EMABLZy 
Its Eaab/K«B 



But Mtaory 
cjcl** o&lj 



Enkbl** Cbtck Bit fs&arfttlob 
ft.nd both CC ftZkd UC raportlnf 
to !!•• Error rag oa CPU Bd 



SCEUB EXABLC/ 
IUb Eaftb/Haa 



Rttrtfli Scrab 
cjelas odI/ 



Eni,bl«B Cb«ck Bit f«D«rfttloa 
and OKLY CC raportlaf 
to M«B Error r»f oa CPU Bd 
CUE raportlns it inhibittd) 



ESABLE CE/ 
!•• Error/CPU 



All 

Bat Mtaory, 
Rtfratb Scrab 



Ea&bltt CE bit io M*a Error 
Rtf ; CE it iiat it th* Error 
Stfttnt bit (DO) ia tb« 
Corrtctftbl* Error R«f oa 
AXY MftB Bd it ftctlT*; CE 
bit it rattt oaly wbia ALL 
Error Sta.tTit bitt a-r* r»t«t 



Cloat) 



But Vaaorx 
cyclat only 



UE bit in Kta Error R»( it 
ftlvftjt •a&blad (k&d it tat 
oa UE raportad to CPU Dd 



EXAfiLE IIT/ 
KaB Error/C?U 



All 
Bqb MaBory. 
Rafratb Scrub 



Enftblat intarrtipt to CPU if 
vaj arror bit in tha lasorj 
Error Rag it ftctira. 
Tha arror bitt. DO:DS. 
inclada tha CE. UE. 
TBACKERR. ftad TIKEOUT bitt. 
(Saa 'Cftcha Error Coadi- 
tiont* in tha Saa-S Cacha 
for IBACKERR, TIHEDUT.) 



10.2.2. Reporting ECC Errors 

Uncorretable and Correctable errors are reported to the CPU or DVMA Master as follows. 

• On DVMA cycles, the OKLY error that is reported to the DVMA Master is an Uncorrectable 
error on the data requested during a DVMA Read cycle. This UE is reported to the Master as 
a bus error. Errors resulting from DVMA Write cycles or cache Write Back cycles resulting 
from DVMA are not reported to the DVMA Master. 

• Correctable and Uncorrectable errors, if enabled, are reported to the processor as interrupts if 
they result from CPU, DVMA. or Write Back bus cycles. Correctable errors resulting from 
refresh scrub cycles, if enabled, arc also reported as interrupts. Uncorrectable errors resulting 
from refresh scrub cycles are not reported. 

• Note that the Memory Error Address register on the processor board does NOT capture the 
failing address of Correctable errors. The Correctable Error Reg on each memory board saves 
this address. The Memory Address Error Reg saves the virtual addresses for Uncorrectable 
errors, Write Back errors, and those Timeout errors reported as interrupts. 



Sun Microsystems Inc 



CONFIDENTL\L 



16 May 1985 



Sun-3 Architecture Rev 2.0 PrcHmTbe Sud-3 ECC Memory Architecture 



&7 



10.3. Device Space Registers for ECC Memory 

In this section, the registers defined in the Device Space (Type 1 access) for ECC control which are on 
memory boards are examined in detail. The Memory Error Control and Memory Error Address registers 
for ECC error reporting are discussed in the section 'Memory Error Registers*. 



10.4. Addressing Registers on ECC Memory Boards 

Each memory board on the Sirius bus contains three different Device Space registers. All of these 
regbters are addressable through a single page in the Device Space. 

iDltialiiAtloft: S«« th» cliiptar oa CPU Rtatt 



rrPE DEVICE ADDR 

(D«co<l« A<20..17>} 



DEVICE 



PRYS. SPACE 



OzOOlEOOOO 



ECC KtBory 



A<7..0> 



Within this page, address bits A7:A6 address the memory board number (set by jumpers). Address bits 
A3:A0 address each of the three registers, as shown below. 



ADDa 



REGISTDl 



DATA TYPE 



A<7..6>cBdi 
A<3..0>=0x0 
A<a..O>=OxA 
A<S..O>=OxQ 



ECC KDt ENABLE 
CORRECTABLE ERA 
ECC CHIP DIAC 



TORD READ-fRITE 

TORO READ-OHLY 
M Bltt fRITE-OJTLY 



The ECC Chip Diagnostic register may only be written by word or longword writes on word (longword) 
boundaries (see below). 

10.4.1. The ECC Memory Enable Register 

ECC memory uses 28 bit physical addressing. The ECC Memory Enable register supports 28 bit 
physical addressing on the memory bus. The contents of this IG bit rcgbter are shown below. 



ECC iE¥ORY ESABLE RECISTER 

BIT MAKE TYPE 

D<5..0> BASE ADDRESS r«»d-»rlt» 

D<6> BOARD ENABLE rtad-writ» 

D<7> BUS ECC OAB r»ad-»rltt 

D<0> SCRUB EHABLE r»wl-wrlt« 

D<10..9> BQAJID SIZE r*tA'onlj 



D<n> DtABLEl DM0 r»kd-*rlt« 

D<12> ENABLE Dil r»kd-wrltt 

D<16..13> BOARD TYPE rtkd-onlj 



KLUIING 



Bita Addr«(f; coap&r* «lth 
bQt k.ddr«it A<27..22> 

OT«rft.ll B»aorj bo&rd (nabl* • 

ECC g*D«rktioii/cb»ck tn&bl* 
on KAMorj bn* ctc1«* 

Enibbl* r«fr**h (crob cjcl* 
tith Corr»ct*blt Err report 

Botrd liz* •ncodin^: 

00 a 4 1(3 

01 c 8 KB 

10 = 16 jm 

11 c 32 MB 
Eimbl* 2960 pin DVO 
Enibl* 2060 pi& Dll 
Bofcrd tjp* idtntlfltr 
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The register contenta are used as follows: 

• The Base Address (D<5..0>) for each memory board is compared with the memory bus 
address (A<27..22>) during each bus memory cycle. (Additional information, not identified 
in the architecture, is required to identify a bus cycle as a memory cycle.) If the Board Enable 
bit (D<6>) b active, then a memory bus cycle is addressed to this memory board if 
A<27..22> b greater than or equal to the Base Address and less than the Base plus the board 
size (i MB to 32 MB, encoded in D<10..9>). 

• The Board Enable bit is initialized to zero when reset, as indicated in the chapter on CPU 
Reset; it must be active to read or write the memory board. 

• The Bus ECC Enable bit enables check bit generation and error reporting for all bus memory 
cycles. All single bit and uncorrectable errors from bus memory cycles are reported to the 
Memory Error Control regbter. 

• The Scrub Enable bit enables a background data scrub during refresh cycles. It also enables 
reporting Correctable errors detected during the refresh scrub. 

• The Board Size field b a Read Only field encoding the board size, 4 MB to 32 MB. 

• Enable DM0 and Enable DM1 are used to control the mode of operation for the 2960 ECC 
chip by driving 2960 pins DM0 and DM1. 

• The Board Type field can be used to identify particular versions of the Memory board. Thb 
field will be coded as O's for the initial version of ECC memory. 

10.4,2. The ECC Memory En ible Register: Initialization 

The ECC memory architecture requires t at memory Base Address registers be initialized with board 

address boundaries which are multiples of i\ • board size. As examples, an 8 MB board must be initialized 

with bit D<0> «= 0; a 16 MB board with •<1..0> = 00; and a 32 MB board with D<2..0> = 000. 

Memory logic comparing A<27..22> with he Base Address field (D<5..0>) may assume that lower 
order Base Address bits meet this restriction 



10.4.3. The Correctable Erro Register 

The 32 -bit Correctable Error Register captures the syndrome and physical address of the first single bit 
error on a memory board. It b reset on a write to the high order byte of the CE register. 



CORRECTABLE EHROR REGISTER 

BIT BAKE TYPE HEAHINC 



D<0> EPJIOR STATUS rtkd-only ActlT* cti.tQ( = CE •rror 

D<23..1> CE ADDRESS r^nd-oaly Rtil Addrtti bit« 

A<25..3> for lint CE 
D<51..2*> SYKDROKE r»fcd-oaly SjTjdro»« for fir»t CE 



The register contents are used as follows: 



• 



The Error Status bit b set active when the first correctable error b detected and reset by a 
Write to the (read only) CE register. The address and syndrome are frozen while the bit is set. 
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• The CE Addrea* field bold* pby»ic>l address biU A<25..3> of the first CE. Real addres* biU 
A<27..26> may be read from the BASE ADDRESS field (biU D<5..4>) in tbe ECC Memory 
Enable register for tbe board. 

• The Syndrome field holds the syndrome of the first CE. 

10.4.4. The ECC Chip Diagnostic Register 

Any implementation of the Sun-3 ECC memory must include control registers to initialize and test the 
ECC generation and check logic. For the first implementation of ECC memory, the AMD 20G0A ECC 
chips are selected for this logic. It is not intended that all implementations of Sun-3 ECC memory be 
restricted to use these AMD chips. 

The first ECC memory utilizes four AMD 2960A ECC chips per memory board. A 16 bit register 
internal to each of these chips controls its initialization and testing. Tbb regbter may be written but not 
read. 

The ECC Chip Diagnostic Register is a logical 64 bit register consisting of the four 16 bit registers inside 
the 2960A chip. Thb regbter must be written as 16 bit words (or 32 bit longwords) on word (longword) 
boundaries. 

See the AMD Data Book for a complete description. 
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